A  SYSTEMS  DEVELOPMENT  METHODOLOGY  FOR 
THE  AUSTRALIAN  ARMY 


iL_  i-# 


,  , , ,  _ Eaiculty  of titielSiSf  Afmy 

/  C(^;^^ailcf  Md'Generil’  St^'ip(0S(e|eTb;pai:^ii 
I  y  FiilfillmMl'Gf  &■  ri^ilireMe^^ 


m:L ... 


I^^TER  OF  MILI’tIrY  ART  AND  SCIENcfe 


/  y} 


r  / .  I  %iv\ 

-  by 


..#f..,  •"  fx 

.S'#--  I  ^ 


€}t 


/G|^^(|)RY  P.' waiters',  M4J,  AUS-U^Ia  - 
B.E.,  UpaverMt/  (|f  l^few  Spdttt^aleS,  3ydfley,  Nev^(Souith  Vales,  1987 
/  MSc.,^jr|nfierdUmversity,'SImvenii^,  U 

i  I  ililP'l  ,  ^iiliO  I  1 

'-Si?" 

61 V 


t  .>^>  '\ 

Fort  Leavenworth,  Kansas 

BELUIMySfecE 


Approved  for  public  release;  distribution  is  unlimited 


STIC  QUALIT7  INSPECTED  4 


19990909  368 


REPORT  DOCUMENTATION  PAGE 

Form  Approved 

0MB  No.  0704-0188 

Pubfc  reportioo  burden  for  thit  cofltction  of  infomiallon  It  Mtimated  to  •«rag#  1  hour  par  respond,  ncfcjding  the 

mainlajning  the  data  needed,  and  completing  and  reviewino  the  collection  of  information.  Send  commenU  legarding  this  burden  ettimrte  or  any  other  atpec*  of  0^  collection  of  informHion. 
including  suggestions  for  reducing  this  burden  to  Wsshinoton  Headquarters  Services.  Directorate  for  (nformation  Operations  arxJ  Repairs,  1215  Jefferson  Da>m  Highway,  Suite  1204,  Arfington, 

VA  22202-4302  and  to  the  Office  of  Management  and  Budget,  Paperwork  Reduction  Project  (0704-0188).  Washington,  DC  20503. 

1 .  AGENCY  USE  ONLY  (Leave  blanki  2.  REPORT  DATE  3.  REPORT  TYPE  AND  DATES  COVERED 

4  Jun  99  Master’s  Thesis  7  Aug  98-4  Jun  99 

4.  TITLE  AND  SUBTITLE 

A  Systems  Development  Methodology  for  the  Australian  Army 

5.  FUNDING  NUMBERS 

6.  AUTHOR(S) 

MAJ  Gregory  P.  Walters 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

U.S.  Army  Command  and  General  Staff  College 

ATTN:  ATZL-SWD-GD 

1  Reynolds  Ave.,  Bldg.  111,  Rm.  123 

Ft  Leavenworth,  KS  66027-1352 

8,  PERFORMING  ORGANIATION 

REPORT  NUMBER 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

10.  SPONSORING/MONITORING 

11,  SUPPLEMENTARY  NOTES 

12a.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  Public  release;  distribution  is  unlimited 

12b.  DISTRIBUTION  CODE 

A 

13.  ABSTRACT  {Maximum  200  words) 

This  study  develops  a  methodology  for  the  Australian  Army  to  adopt  to  ensure  th; 
applied  to  the  concept  and  acquisition  phases  of  the  Materiel  Cycle.  This  involve 
Systems  Engineering,  Integrated  Logistics  Support,  and  Logistics  Support  Analys 
each  of  these  disciplines  separately  before  considering  their  relationship  VYith  one 
methodology  is  then  produced  which  integrates  these  disciplines. 

The  organisations  involved  in  the  concept  and  acquisition  phases  of  the  material  c 
study  proposes  that  the  key  organizations  for  Army  are  the  Combined  Arms  Train 
Center,  the  Land  Development  Branch  within  the  Capability  Development  Divisic 
Programming  and  Resource  Planning  Division,  and  the  Defence  Acquisition  Orga 
Key  documentation  in  the  concept  and  acquisition  phases  of  the  material  cycle  is  i 
proposes  that  the  key  organizations  apply  the  systems  development  methodology 
documentation  in  the  concept  and  acquisition  phases  of  the  material  cycle. 

14  SUBJECT  TERMS 

Systems  Engineering:  Integrated  Logistics  Support;  Logistic  Support  Analysis; 
Systems  Development  Methodology;  Australian  Army 

at  a  systems  approach  is 
s  an  integration  of 
is.  The  study  examines 
another.  A 

ycle  are  examined.  The 
ling  and  Development 
m,  the  Capability 
inisation. 

identified.  The  study 
to  the  production  of  key 

15.  NUMBER  OF  PAGES 

92 

16.  PRICE  CODE 

17.  SECURITY  CLASSIFICATION  18.  SECURITY  CLASSIFICATIOK  19.  SECURITY  CLASSIFICATION 

OF  REPORT  OF  THIS  PAGE  OF  ABTRACT 

UNCLASSIFIED  UNCLASSIFIED  UNCLASSIFIED 

20.  LIMITATION  OF 

ABSTRACT 

UL 

NSN  7540-01-280-5500 


Standard  Form  298  (Rev.  2-89) 


MASTER  OF  MILITARY  ART  AND  SCIENCE 
THESIS  APPROVAL  PAGE 

Name  of  Candidate:  MAJ  Gregory  Peter  Walters 

Thesis  Title:  A  Systems  Development  Methodology  for  the  Australian  Army 


Approved  by: 


Accepted  this  4th  day  of  June  1999  by: 

Philip  J.  Brookes,  Ph.D. 


,  Director,  Graduate  Degree  Programs 


The  opinions  and  conclusions  expressed  herein  are  those  of  the  student  author  and  do  not 
necessarily  represent  the  views  of  the  U.S.  Army  Command  and  General  Staff  College  or 
any  other  governmental  agency.  (References  to  this  study  should  include  the  foregoing 
statement.) 


11 


ABSTRACT 


A  SYSTEMS  DEVELOPMENT  METHODOLOGY  FOR  THE  AUSTRALIAN  ARMY 
by  MAJ  Gregory  P.  Walters,  Australia,  92  pages 

This  study  develops  a  methodology  for  the  Australian  Army  to  adopt  to  ensure  that  a 
systems  approach  is  applied  to  the  concept  and  acquisition  phases  of  the  Materiel  Cycle. 
This  involves  an  integration  of  Systems  Engineering,  Integrated  Logistics  Support,  and 
Logistics  Support  Analysis.  The  study  examines  each  of  these  disciplines  separately 
before  considering  their  relationship  with  one  another.  A  methodology  is  then  produced 
which  integrates  these  disciplines. 

The  organisations  involved  in  the  concept  and  acquisition  phases  of  the  material  cycle  are 
examined.  The  study  proposes  that  the  key  organizations  for  Army  are  the  Combined 
Arms  Training  and  Development  Center,  the  Land  Development  Branch  within  the 
Capability  Development  Division,  the  Capability  Programming  and  Resource  Planning 
Division,  and  the  Defence  Acquisition  Organisation. 

Key  documentation  in  the  concept  and  acquisition  phases  of  the  material  cycle  is 
identified.  The  study  proposes  that  the  key  organizations  apply  the  systems  development 
methodology  to  the  production  of  key  documentation  in  the  concept  and  acquisition 
phases  of  the  material  cycle. 
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CHAPTER  1 


INTRODUCTION  AND  OVERVIEW 

On  6  July  1998,  Admiral  C.  A.  Barrie,  the  incoming  Chief  of  the  Australian 
Defence  Force,  issued  a  message  to  all  Australian  Defence  Force  members,'  cosigned  by 
the  senior  members  of  the  Defence  Executive.  In  it  he  called  for  a  fundamental  review  of 
all  capability  processes,  and  for  the  development  of  appropriate  processes  and  systems 
that  would  see  a  capability  managed  throughout  its  entire  life,  “from  the  first  bright  idea, 
through  force  development,  acquisition,  in-service  usage,  until  disposal.”^  The  challenge 
was  to  determine  what  methodology  the  Australian  Defence  Force  should  adopt  to  ensure 
that  a  systems  approach  was  applied  throughout  a  capability’s  life  cycle. 

Studies  conducted  by  the  US  DOD^  of  defence  projects  over  the  past  twenty  years 
examined  the  process  of  taking  a  capability  from  its  initial  conception  through  to  fielding 
in  service.  They  showed  that  if  a  change  to  increase  supportability  were  made  during  the 
design  process  and  cost  $1 .00,  that  same  change  made  during  production  would  cost 
$100,000.  If  the  change  was  not  made  until  after  introduction,  the  cost  would  escalate  to 
$1,000,000. 

The  need  for  effective  capability  development  is  also  important  to  the  warfighter 
because  it  directly  affects  their  ability  to  prosecute  war.  If  the  requirements  for  a  new 
system  are  inadequately  defined  then  the  warfighter’s  needs  will  not  be  met  and  it  will 
only  be  after  an  equipment  is  introduced  into  service  that  they  will  find  it  does  not  do 
what  they  want  it  to  do.  Furthermore,  they  are  likely  to  find  that  they  can  not  fight  with  it 
because  it  does  not  meet  their  concept  of  operations;  they  do  not  have  the  resources  to 
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support  it;  and  it  places  an  additional  maintenance  burden  on  their  already  stretched 
resources.  If  the  system  requirements  are  uimecessarily  over-specified  then  the  system  is 
almost  guaranteed  to  cost  more,  which  means  that  he  either  receives  less  of  that 
equipment  or  less  of  another  required  capability.  Either  way  the  warfighter  loses. 

Problem  Statement 

This  study  examines  the  process  of  developing  and  acquiring  a  capability  for  the 
Australian  Army.  It  develops  a  methodology  for  implementing  a  systems  approach  in  the 
concept  and  acquisition  phases  of  the  materiel  cycle. 

In  developing  the  methodology,  the  study  examines  the  use  of  Systems 
Engineering,  Integrated  Logistics  Support  (ILS)  and  Logistic  Support  Analysis  (LSA). 
ILS  and  LSA  are  already  established  as  part  of  the  capability  development  and 
acquisition  process.  They  are  used  throughout  defence  to  ensure  a  systematic  approach  is 
taken  to  developing  the  logistics  requirements  for  a  new  capability.  Systems  Engineering 
is  not  as  well  developed. 

The  reason  for  examining  Systems  Engineering  is  that  the  Australian  Defence 
Acquisition  Organisations  (DAO)  commissioned  a  study  titled  the  DAO  Systems 
Engineering  Study,  to  assess  the  implementation  of  Systems  Engineering  within  its 
organisation.  The  report  recommended  that  Systems  Engineering  processes  and 
procedures  be  adopted  across  the  three  services  within  the  acquisition  phase  of  the 
materiel  cycle.  The  Army’s  Combined  Arms  Training  and  Development  Centre 
(CATDC)  also  decided  to  use  Systems  Engineering  software  to  manage  its  requirements 
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development  process.  Both  of  these  are  key  organisations  within  the  concept  and 
acquisition  phases. 

This  study  examines  how  Systems  Engineering,  ILS  and  LS  A  can  be  integrated  to 
produce  a  systems  development  methodology  for  the  Australian  Army  which  can  be 
applied  in  the  concept  and  acquisition  phases  of  the  materiel  cycle. 

Research  Question 

What  methodology  should  the  Australian  Army  adopt  to  ensure  that  a  systems 
approach  is  applied  to  the  concept  and  acquisition  phases  of  the  materiel  cycle? 

Backgroimd 

There  is  currently  no  formal  methodology  within  the  Australian  Army  for 
implementing  a  systems  approach  in  the  capability  development  and  acquisition  phases  of 
their  materiel  cycle.  The  methodology  that  the  US  uses  is  based  on  the  Systems 
Engineering  approach,  to  which  ILS  and  LSA  are  applied. 

The  Systems  Engineering  process  used  in  the  US  DoD  has  historically  been  based 
on  various  evolutions  of  MIL-STD-499,  System  Engineering  Management.  The  standard 
was  developed  to  integrate  with  the  US  DoD  acquisition  system.  However,  the  four 
phases  of  the  Australian  Defence  materiel  cycle  do  not  match  the  US  DoD  Acquisition 
process.  The  US  standard,  therefore,  could  not  be  applied  to  the  Australian  Defence 
materiel  cycle  without  being  tailored  to  meet  the  needs  of  the  Australian  system. 

In  the  US  DoD  the  use  of  ILS  has  traditionally  been  based  on  MIL  STD  1388  and 
the  use  of  LSA  has  been  based  on  MIL  STD  1388  lA  and  MIL  STD  1388  2B.  These 
standards  are  still  used  within  the  Australian  Defence  Force. 
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The  Defence  Acquisition  Organisations  and  the  Combined  Arms  Training  and 
Development  Centre  are  increasingly  aware  of  the  use  of  Systems  Engineering  in  the 
capability  development  and  acquisition  phases  of  an  equipment’s  life  cycle.  However,  at 
present  within  the  Australian  Army,  Systems  Engineering  principles  are  only  applied  in 
an  ad  hoc  manner.'*  The  implementation  of  these  principles  is  usually  as  a  result  of  the 
efforts  of  a  particular  desk  officer,  and  the  results  are  usually  limited  to  their  project  or 
area  of  development.  There  exists  no  policy  for  the  implementation  of  Systems 
Engineering  within  the  Australian  Army,  no  formal  requirement  for  its  use,  and  no 
champion  for  its  implementation. 

The  DAO  Systems  Engineering  Study  examined  the  integration  of  Systems 
Engineering  across  the  three  services  within  the  DAO.  This  study  was  defence  wide  and 
applied  only  to  the  acquisition  phase  of  the  materiel  cycle.  There  has  been  no  study 
conducted  to  look  at  how  the  Australian  Army  can  apply  a  systems  approach  in  both  the 
concept  and  acquisition  phases  of  the  materiel  cycle. 

Study  Method 

There  are  three  areas  that  are  well  defined  in  the  current  body  of  knowledge. 

They  are  Systems  Engineering,  ILS  and  LSA.  This  study  will  examine  the  existing 
documentation  in  these  areas  with  a  view  to  providing  a  synthesis,  which  can  be  applied 
within  the  Australian  Army. 

The  first  step  is  to  examine  the  Australian  Army’s  materiel  processes  to  determine 
the  context  within  which  this  synthesis  can  be  applied.  This  examination  includes  the 


4 


materiel  cycle,  key  documentation  requirements,  the  approval  process,  and  the  role  of 
committees. 

Systems  Engineering,  ILS  and  LSA  are  then  examined  separately  followed  by  an 
examination  of  the  relationship  between  each  of  these  disciplines.  Particular  emphasis  is 
placed  on  the  relationship  between  LSA  and  Systems  Engineering. 

This  analysis  provides  the  basis  for  detailing  a  methodology  for  the  Australian 
Army  to  implement  a  systems  approach  in  the  capability  development  and  acquisition 
phases  of  the  materiel  cycle. 

Systems  Development  Disciplines 

The  two  major  disciplines  that  will  be  examined  are  Systems  Engineering  and 
ILS.  LSA  will  be  examined  because  it  is  the  tool  that  integrates  ILS  and  the  engineering 
functions.  Project  management  is  discussed  because  it  is  the  discipline  that  applies  the 
skills  to  manage  the  capability  development  and  acquisition  process. 

Systems  Engineering  is  an  interdisciplinary  approach  that  aims  to  deliver  systems 
providing  an  optimum,  balanced,  coherent  solution  to  satisfy  customer  needs.  It  is  an 
orderly,  structured,  disciplined,  and  systematic  process.  It  attacks  large  problems  by 
breaking  them  down  into  smaller  ones,  and  ensures  that  the  solutions  of  the  smaller 
problems  are  integrated  into  the  solution  of  the  larger  problem.  An  important  aspect  of 
this  process  is  traceability  and  accountability.  The  process  examines  all  of  the  elements 
that  interface  with  a  system.  In  this  way  it  seeks  to  optimize  the  quality  of  a  system 
throughout  its  entire  life  cycle. 
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As  applied  to  an  Army  equipment  system,  Systems  Engineering  includes  but  is 
not  limited  to,  capability  development,  project  management,  engineering,  and  logistics. 
Striking  an  optimum,  balanced,  and  coherent  solution  means  making  sound  trade-offs 
between  capability  and  supportability,  acquisition  and  life  cycle  support,  and  quantity 
versus  quality. 

Systems  engineering  is  a  management  or  problem-solving  approach,  rather  than  a 
technical  approach,  even  though  there  are  specific  standards  that  outline  its 
implementation.  It  is  comprised  of  the  following  key  activities,  which  are  applied 
iteratively  to  successive  layers  of  the  system: 

a.  Requirements  Analysis.  This  analyses  the  requirements  to  ensure  they  are 
complete,  understandable  and  traceable. 

b.  Functional  Analysis/Allocation.  This  breaks  down  the  system  to  the  next 
layer  of  definition  and  allocates  the  requirements  to  the  system’s  functional 
components. 

c.  Design  Synthesis  and  Verification.  This  translates  the  requirements  into 
possible  solutions  and  evaluates  the  progress  of  the  evolving  system  and  its 
effectiveness  at  meeting  the  original  requirements. 

d.  Systems  Analysis  and  Control.  This  evaluates  each  alternative  in  terms  of  its 
capability  to  meet  the  requirements  and  then  selects  the  optimal  one.  The  process 
is  monitored  and  controlled  to  ensure  that  it  is  still  meeting  the  original  intent  for 
which  it  was  designed. 
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ILS  is  another  whole  of  life  management  discipline  that  aims  to  deliver  a 
complete  system  that  meets  the  user’s  needs.  It  aims  to  integrate  all  support  and  service 
considerations  for  a  materiel  system  and  provide  a  seamless  transition  of  support 
activities  between  each  phase  of  the  materiel  cycle. 

Within  the  concept  and  acquisition  phases,  ILS  aims  to  ensure  that* 

a.  consideration  of  support  factors  is  integral  to  the  development  of  capability 

options, 

b.  support  considerations  influence  design  requirements  and  selection, 

c.  requirements  are  used  in  optimizing  a  materiel  system’s  performance, 

d.  support  elements  are  acquired  or  implemented.^ 

LSA  is  the  tool  that  integrates  ILS  and  the  engineering  functions.  It  is  made  up  of 
a  series  of  tasks  that  when  performed  ensure  that  each  element  of  ILS  is  considered  along 
with  the  system  design.  LSA  provides  a  single  analytical  approach  to  enable  support 
considerations  to  influence  the  design  requirements  and  design  selection  for  a  materiel 
system. 

Project  management  is  a  discipline  to  manage  the  capability  development  and 
acquisition  process.  As  such.  Systems  Engineering,  project  management  and  ILS  are 
interrelated.  The  intelligent  and  tailored  application  of  good  Systems  Engineering, 
project  management  and  ILS  principles  has  proven  to  help  bring  projects  in  on  schedule, 
within  budget  and  with  optimal  life-cycle  cost.  It  also  helps  to  satisfy  end  users’  and 
environmental  requirements,  and  to  consider  all  relevant  constraints. 
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The  Australian  Defence  Force’s  approach  to  capability  development  and 
acquisition  incorporates  Systems  Engineering,  project  management  and  ILS  principles, 
but  not  systematically  or  consistently.  The  Australian  Defence  industry  has  pointed  out 
that  essential  elements  of  the  approach  are  either  missing  or  not  applied  properly.  In  most 
cases  the  failure  is  due  to  an  ill-defined  statement  of  requirements  and  inadequate 
management  of  the  scope  of  the  project.  Project  budgets,  human  resource  requirements, 
and  schedules  are  often  derived  without  a  sufficiently  systematic,  rigorous,  or  auditable 
approach.  They  often  lack  a  proper  application  of  work  linked  to  resource  requirements. 
These  failures  result  largely  from  systemic  problems  rather  than  failures  on  the  part  of 
individuals. 

There  is  currently  no  Australian  Defence  Force  or  Australian  Army  policy 
document  that  ties  Systems  Engineering,  project  management,  and  ILS  together,  nor  is 
there  a  document  that  addresses  the  integration  of  Systems  Engineering  across  the 
Australian  Defence  Force  or  Army.  Prior  to  the  DAO  Systems  Engineering  Study 
completed  in  1999,  the  Defence  Systems  Engineering  Working  Party  conducted  a  study 
to  investigate  the  applicability  of  Systems  Engineering  within  defence.  They 
recommended  the  adoption  of  Systems  Engineering.  Their  draft  report  was  tabled  in 
November  1996. 

Scope 

This  study  proposes  a  methodology  for  the  Australian  Army  to  ensure  that  a 
systems  approach  is  applied  to  the  capability  development  and  acquisition  phases  of  the 
materiel  cycle.  It  focuses  on  the  integration  of  Systems  Engineering,  ILS,  and  LSA 
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within  the  concept  and  acquisition  phases  of  the  Australian  Army’s  materiel  cycle.  It  will 
not  examine  the  in-service  or  disposal  phases. 

This  study  considers  the  organisational  aspects  of  integration  and  will  use  non¬ 
software  projects  as  a  basis  for  discussion.  It  will  not  examine  the  use  of  specific 
Systems  Engineering  tools  or  products  nor  attempt  to  conduct  a  detailed  cost  benefit 
analysis  of  the  implementation  of  the  Systems  Engineering  approach. 

Assumptions 

The  DAO  Systems  Engineering  study  and  the  earlier  work  done  by  the  Defence 
Systems  Engineering  Working  Party  in  1996  determined  that  there  was  benefit  in 
applying  the  Systems  Engineering  approach  to  the  Australian  Defence  Force.  US  DoD 
Instruction  5000.2-R  mandates  that  Systems  Engineering  be  applied  throughout  a 
system’s  life  cycle.  It  states,  “The  Program  Manager  shall  ensure  that  a  Systems 
Engineering  process  is  used  to  translate  operational  needs  and/or  requirements  into  a 
system  solution  that  includes  the  design,  manufacturing,  test  and  evaluation,  and  support 
processes  and  products.”* 

The  Australian  Defence  Instruction  (General)  LOG  03-6  [DI(G)  LOG  03-6] 
directs  that,  “As  supportability  is  an  integral  component  of  performance,  ILS  principles 
and  practices  will  be  applied  to  projects  during  both  the  pre-approval  and  acquisition 
phases  to  ensure  that  materiel  systems  are  acquired  that  meet  performance  specifications 
at  minimum  life  cycle  costs.”’  It  also  states  that,  “Systems  Engineering  and  ILS,  when 
combined,  provide  a  life  cycle  focus  for  managing  the  design  and  support  efforts  (for  a 
system  or  modification  to  a  system).”® 
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It  is  therefore  assumed  that  the  tailored  application  of  good  Systems  Engineering, 
project  management  and  ILS  principles  assist  with  bringing  projects  in  on  schedule, 
within  budget,  and  with  optimal  life-cycle  cost.  It  also  is  assumed  that  these  assist  in 
satisfying  end  users’  needs  and  environmental  constraints  and  that  the  process  allows  the 
consideration  of  all  relevant  constraints  and  impacts.  Finally,  it  is  assumed  that  the 
Australian  Army  will  benefit  from  the  implementation  of  a  systems  approach  in  the 
concept  and  acquisition  phases  of  the  materiel  cycle. 

Key  Terms 

Definitions  of  key  terms  come  from  the  engineering  standard  EIA/IS  632. 
Additional  definitions  are  provided  for  clarity.  Key  terms  include: 


>^stems  Engineerint 


Engineering  standard  EIA/IS  632:  defines  Systems  Engineering  as: 

An  interdisciplinary  approach  encompassing  the  entire  technical  effort  to 
evolve  and  verify  an  integrated  and  life  cycle  balanced  set  of  system  people, 
product  and  process  solutions  that  satisfy  customer  needs. 

Systems  Engineering  encompasses: 

a.  the  technical  efforts  related  to  the  development,  manufacturing, 
verification,  deployment,  operations,  support,  disposal  of,  and  user 
training  for,  system  products  and  processes 

b.  the  definition  and  management  of  the  system  configuration; 

c.  the  translation  of  the  system  definition  into  work  breakdown  structures; 

d.  the  development  of  information  for  management  decision  making.® 

The  DAO  Systems  Engineering  Study  provides  a  definition  based  on  EIA/IS  632. 


It  defines  Systems  Engineering  as: 


The  conduct  of  engineering  based  on  systems  principles.  Good  practice  is 
characterized  by  an  interdisciplinary  approach  encompassing  the  entire  technical 
effort  to  evolve  and  verify  an  integrated  and  life-cycle  balanced  set  of  system 
product,  people  and  process  solutions  that  satisfy  customer  needs.  Systems 
Engineering  encompasses: 


a.  the  definition  and  management  of  the  system  configuration; 

b.  the  translation  of  the  system  definition  into  work  breakdown  structure 
for  management  piupose;  and 

c.  development  of  information  for  use  by  stakeholders  other  than  the 
performing  entity.'® 

IEEE  Std  1220-1994  defines  Systems  Engineering  as  an  interdisciplinary 
collaborative  approach  to  derive,  evolve,  and  verify  a  life  cycle  balanced  system  solution 
that  satisfies  customer  expectations  and  meets  public  acceptability. 

Systems  Engineering  Process 
EIA/IS  632  defines  the  Systems  Engineering  process  as: 

A  comprehensive,  iterative,  problem  solving  process  that: 

a.  transforms  validated  customer  needs  and  requirements  into  a 
description  of  a  life  cycle  balanced  solution  set  of  people,  products  and 
processes; 

b.  generates  information  for  decision  makers; 

c.  provides  information  for  follow-up  technical  efforts." 

The  DAO  Systems  Engineering  Study  provides  a  definition  based  on  EIA/IS  632. 
It  defines  the  Systems  Engineering  process  as: 

A  comprehensive,  iterative,  problem  solving  process  that: 

a.  identifies  and  validates  customer/tasking  entity  needs  and  requirements; 

b.  transforms  validated  customer/tasking  entity  needs  and  requirements 
into  a  description  of  a  life-cycle  balanced  solution  set  of  products, 
processes  and  people; 

c.  generates  information  for  decision  making;  and 

d.  provides  information  for  follow-on  technical  efforts.'^ 

Key  Systems  Engineering  Activities 

EIA/IS  632  defines  the  four  key  Systems  Engineering  activities  as  requirements 
analysis,  functional  analysis/allocation,  design  s)mthesis  and  verification,  and  system 
analysis  and  control.  The  definitions  of  each  of  these  activities  are  as  follows: 
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a.  Requirements  Analysis.  Requirements  Analysis  is  the  determination  of  system 
specific  performance  and  functional  characteristics  based  on  analyses  of  customer 
needs,  requirements,  and  objectives;  missions/operations;  projected  utilisation 
environments  for  people,  products,  processes;  constraints;  and  measures  of 
effectiveness.  It  is  the  bridge  between  customer  requirements  and  system  specific 
requirements  from  which  solutions  can  be  generated  for  the  primary  system 
functions. 

b.  Functional  Analysis/ Allocation.  Functional  Analysis/Allocation  is  the 
examination  of  a  detailed  function  to  identify  all  the  sub-functions  necessary  for 
the  accomplishment  of  that  function,  identification  of  functional  relationships  and 
interfaces  (internal  and  external)  and  capturing  of  these  in  a  functional 
architecture.  It  includes  the  flowdown  of  upper  level  performance  requirements 
and  assignment  of  these  to  lower  level  sub-functions. 

c.  Design  Synthesis  and  Verification. 

1 .  Synthesis.  Synthesis  is  the  translation  of  input  requirements  (including 
performance,  function  and  interface)  into  possible  solutions  (resources  and 
techniques)  satisfying  these  inputs.  It  defines  a  physical  architecture  of 
people,  product  and  process  solutions  for  logical  groupings  of  requirements 
(performance,  function  and  interface)  and  then  designs  these  solutions. 

2.  Verification  Fxmction.  The  verification  function  includes  the  tasks,  actions, 
and  activities  to  be  performed  to  evaluate  progress  and  effectiveness  of 
evolving  system  (people,  product  and  process)  solutions  and  to  measure 
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compliance  with  requirements.  Analysis  (including  simulation), 
demonstration,  test,  and  inspection  are  verification  approaches  used  to 
evaluate  risk;  people,  product,  and  process  capabilities;  compliance  with 
requirements;  and  proof  of  concept. 

d.  System  Analysis  and  Control.  System  Analysis  and  Control  is  the  imposition 
of  structure  and  discipline  into  a  system  evolution  by  measuring  progress  based 
on  demonstrated  performance;  identifying,  developing  and  examining 
alternatives;  making  decisions  based  on  cost,  schedule,  performance,  and  risk  to 
effect  balanced  results;  documenting  the  evolution  and  rationale,  and  controlling 
resulting  configurations. 


'Admiral  Barrie  stated,  “We  are  going  to  ensure  that  Defence  manages  whole  of 
life  capability  through  seamless  management. ...  We  will  establish  the  appropriate 
underlying  processes  and  systems  needed  for  this. . . .  The  result  will  be  that  our  systems 
meld  together  all  of  the  elements  that  go  into  building  an  effective  defence  force.” 

^Admiral  C.  A.  Barrie  et  al.,  A  Message  to  all  Defence  Personnel  from  the 
Executive,  letter  Australian  Defence  Force,  Canberra,  6  July  1998. 

’K.  Gascoyne  and  P.  King,  ILS  Awareness  Course-Student  Notes,  (Canberra: 
Computer  Power  and  Total  Logistics  Management,  28  March  1996),  2. 

“Based  on  the  authors  own  observations  and  the  findings  of  the  “DAO  Systems 
Engineering  Study”  (1999)  and  the  findings  of  the  “Study  of  the  Applicability  and 
Application  of  Systems  Engineering  within  Defence-Final  Draft”  (Nov  1996). 

^Australian  Department  of  Defence,  Defence  Instruction  (General)  LOG  03-6  - 
Defence  Policy  on  Integrated  Logistics  Support,  (Canberra:  Commonwealth  of  Australia, 
26  May  1997),  1. 

®US  DoD  Instruction  5000.2,  Mandatory  Procedures  for  Major  Defence 
Acquisition  Programs  (MDAPs)  and  Major  Automated  Information  System  (MAIS) 
Acquisition  Programs,  (Washington  DC:  US  DoD,  15  March  1996),  Part  4,  Section  4-3, 
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’Australian  Department  of  Defence,  Defence  Instruction  (General)  LOG  03-6, 2. 
*Ibid.,  Annex  B,  B-1. 

’Australian  Department  of  Defence,  Draft  Defence  Instruction  (General)  LOG  08- 
XX  The  Application  of  Systems  Engineering  in  Capital  Equipment  Acquisition  and  In- 
Service  Support,  (Canberra:  Commonwealth  of  Australia,  12  December  1996),  Annex  A, 

1. 


‘"Technology  Australasia,  Standard  No  001,  Systems  Engineering,  Issues  3, 20 
September  1996, 14. 

“Australian  Department  of  Defence,  Draft  Defence  Instruction  (General)  LOG 
08-XX,  Annex  A,  1,2. 

‘’Technology  Australasia,  15. 
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CHAPTER  2 


REVIEW  OF  LITERATURE 
Systems  Engineering 

This  study  considered  three  major  Systems  Engineering  Standards.  They  are: 

a.  MIL-STD  499B,  Systems  Engineering,  Draft  06  May  92; 

b.  EIA/IS  632,  US  Electronic  Industries  Association  Interim  Standard  632,  dated 

December  1994;  and 

c.  (3)  IEEE  Standard  1220-1994,  US  Institute  of  Electrical  and  Electronics 

Engineers  Trial-Use  Standard for  Application  and  Management  of  the  Systems 

Engineering  Process,  dated  February  1995. 

To  date  the  use  of  systems  engineering  within  the  ADF  has  followed  the  US 
model  as  defined  in  military  standards  MIL-STD-499/A/B  even  though  MIL-STD-499B 
was  never  officially  released.  When  it  became  clear  in  June  1994  that  MIL-STD  499B 
(Draft)  was  not  going  to  be  released  by  the  US  government  as  a  result  of  a  move  away 
firom  the  use  of  military  standards,  the  US  Electronic  Industries  Association  agreed  to 
undertake  the  task  of  “demilitarizing”  the  document  and  releasing  it  as  an  industry 
standard.  As  a  result,  MIL-STD-499B  was  converted  into  the  commercial  standard 
EIA/IS-632  1994,  Systems  Engineering.  The  purpose  of  this  standard  was  to  aid  the 
integrated  development,  realization,  or  improvement  of  system  products  and  processes.  It 
also  set  out  to  help  developers: 

a.  identify  and  balance  the  competing  requirements  between  different 

stakeholders; 

b.  establish  and  develop  technical  requirements; 
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c.  ensure  that  technical  requirements  were  met  within  cost,  schedule  and  risk 
constraints;  and 

d.  provide  products  that  met  stakeholders’  needs. 

As  EIA/IS-632  was  based  on  a  military  standard,  it  was  necessary  to  create  a 
standard  that  was  more  appropriate  to  the  commercial  application  of  Systems 
Engineering.  As  a  result  IEEE  1220-1994,  IEEE  Trial-Use  Standard for  Application  and 
Management  of  the  Systems  Engineering  Process,  was  released  in  1995.  It  is 
significantly  different  from  EIA/IS-632,  even  though  the  basic  higher  level  processes  are 
quite  similar.  Its  purpose  was  to  provide  a  standard  for  managing  a  system  from  initial 
concept  through  development,  operations,  and  disposal,  and  it  focuses  on  the  systems 
engineering  process.  IEEE  1220  gives  a  more  detailed  treatment  of  both  systems 
engineering  process  tasks  and  life  cycle  phases  than  EIA/IS  632. 

Both  of  these  standards  are  currently  being  reviewed.  An  international  standard 
for  system  life  cycle  processes,  ISO  15288,  is  also  under  development  but  it  is  currently 
unknown  when  this  standard  is  likely  to  be  released.*  The  development  of  Systems 
Engineering  standards  is  shown  in  figure  1  ? 

Technology  Australasia,  one  of  Australia’s  leading  practitioners  and  educators  of 
Systems  Engineering  for  the  ADF,  has  also  produced  a  systems  engineering  standard. 
Issue  3  was  released  in  September  1996.  Its  intent  is,  “to  assist  in  defining,  performing, 
managing  and  evaluating  Systems  Engineering  efforts  in  system  acquisitions  and 
technology-based  system  developments.”^  It  adapts  MIL-STD-499B  for  general 
application  with  the  intent  of  improving  aspects  of  the  last  draft. 
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A  number  of  companies,  such  as  TDA  Systems  Engineering,  Ball  AeroSpace  and 
Technologies,  and  Technology  Australasia,  who  teach  Systems  Engineering  to  Australian 
Defence  personnel,  have  produced  course  notes  and  handbooks  on  the  use  of  Systems 
Engineering  within  the  Australian  Defence  Force.  This  study  has  drawn  on  course 
materiel  from  the  systems  engineering  courses  run  by  Technology  Australasia  in 
September  1995,  TDA  Systems  Engineering,  and  Ball  Aerospace  and  Technologies 
Group  in  September— October  1997,  and  TDA  Systems  Engineering  in  May  1998. 


Other 

^  1  Standards 
/ 

/  - 

/ 

I 

/ 


Figure  1.  Development  of  Systems  Engineering  Standards 
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There  is  currently  no  ADF  or  Australian  Army  document  that  addresses  the 
integration  of  systems  engineering  across  the  ADF  or  Army.  However,  a  draft  report 
fi’om  the  Defence  Systems  Engineering  Working  Party,  which  was  established  to  study 
the  applicability  and  application  of  systems  engineering  within  Defence,  has  been 
produced. 

The  DAO  Systems  Engineering  Study,  was  undertaken  by  Technology  Australasia 
under  a  contract  with  the  Coimnonwealth  of  Australia.  Its  purpose  was  to  assess  the 
implementation  of  systems  engineering  within  the  Defence  Acquisition  Organisation  of 
the  Department  of  Defence,  Commonwealth  of  Australia.  The  contract  was  managed  by 
the  Director  Acquisition  Management  Systems  (Systems  Engineering)  (DAMS(SE)). 

The  overall  objective  of  the  study  was  to  determine  the  appropriate  requirements 
for  the  successful  application  of  systems  engineering  in  the  acquisition  of  major  capital 
equipment  by  the  Australian  Department  of  Defence.  It  is  therefore  limited  to  the 
application  of  systems  engineering  in  major  projects  in  the  Defence  Acquisition 
Organisation. 

Another  major  study  into  systems  engineering  within  defence  was  conducted  in 

1995/96  by  the  Defence  Systems  Engineering  Working  Party  (SEWP).  The  SEWP  was 

formed  under  the  direction  of  the  Defence  Logistics  Policy  Consultative  Group  to  study 

the  applicability  and  application  of  systems  engineering  in  defence,  as  a  prerequisite  to 

policy  development.  Its  aim  was  to  determine  the  applicability  of  Systems  Engineering 

in  defence  and  the  most  appropriate  means  of  implementing  Systems  Engineering 

principles,  policy,  and  procedures.  It  was  completed  in  approximately  twelve  months  and 

was  based  on  extensive  interviews  with  stakeholders  and  projects  within  the  Australian 
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Department  of  Defence,  defence  industry,  and  providers  of  systems  engineering 
education  and  training. 

The  SEWP  study  found  that  Systems  Engineering  is  applicable  to  defence.  It 
confirmed  the  need  to  formalize  the  application  of  Systems  Engineering  principles  within 
defence  and  recommended  the  establishment  of  a  Systems  Engineering  Support  Office  to 
carry  out  a  phased  implementation  strategy.  Its  final  report  was  not  endorsed.  It  appears 
that  lack  of  resources  to  implement  the  report’s  recommendations  was  a  major 
contributing  factor. 

Within  the  US,  US  DoD  Instruction  5000.2-R  dated  15  March  1996  details  the 
mandatory  procedures  for  Major  Defence  Acquisition  Programs  and  Major  Automated 
Information  System  Acquisition  Programs.  This  instruction  mandates  the  use  of  Systems 
Engineering. 

The  Materiel  Cycle  and  Processes 

The  materiel  cycle  and  processes  are  documented  in  the  Capital  Equipment 
Procurement  Manual  (CEPMAN)  Volumes  One  and  Two.  The  Major  Capital 
Acquisition  process  is  also  taught  by  a  number  of  Australian  Defence  Contractors  such  as 
Kmhill  Engineering.  Handbooks  are  produced  on  these  courses.  This  study  used 
materiel  from  a  course  on  the  Major  Capital  Acquisition  Process  run  by  Total  Logistics 
Management  and  Kinhill  Engineers  in  October  1997. 

Integrated  Logistics  Support 

Integrated  Logistics  Support  (ILS)  is  well  covered  in  numerous  articles  and 
books.  Defence  Instruction  (General)  [DI(G)]  LOG  03-6  provides  the  Australian 
Defence  Policy  on  ILS  and  the  Australian  Department  of  Defence  Logistic  Support 
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Manual  (LOGMAN)  provides  policy  and  procedural  support  on  logistic  support, 
including  ILS,  for  use  within  defence. 

Defence  contractors  run  numerous  courses  for  defence  personnel  on  the  use  of 
ILS  within  defence.  This  study  used  materiel  from  an  ILS  Awareness  Course  run  by  the 
Computer  Power  Group  and  Total  Logistics  Management  in  October  1996  and  a  Short 
ILS  Course  run  by  the  same  companies  in  May  1997. 

There  is  currently  no  Australian  Defence  Force  or  Australian  Army  policy 
document  that  ties  systems  engineering,  ILS,  and  the  materiel  cycle  processes  together. 

Capability  Management  Improvement  Team 

In  accordance  with  the  CDF’s  message  to  all  defence  personnel  on  6  July  1998, 
DEFGRAM  187/98  (06  August  1998)  authorized  the  formation  of  a  Capability 
Management  Improvement  Team  (CMIT)  to  assist  in  the  improvement  of  capability 
management  within  Defence. 

The  CMIT  is  to  take  a  broad  view  of  capability,  which  encompasses  whole  of  life 
considerations  and  the  principal  factors  that  contribute  to  effectiveness.  The  CMIT  aims 
to  overcome  the  current  segmentation  of  capability  management  that  currently  exists 
within  defence,  and  achieve  a  more  seamless  life  cycle  management  of  capability.  The 
outcomes  of  the  team’s  study  will  have  a  major  impact  on  the  nature  and  implementation 
of  any  systems  development  methodology  proposed  for  defence. 

‘Technology  Australasia,  Defence  Acquisition  Organisation  Systems  Engineering 
Study  (Final  Report  Draft  C),  (Canberra:  Technology  Australasia,  1  October  1998),  43. 

^Dr  J.  Lake,  Presentation— Standards  that  can  help  the  Engineering  of  Better 
Systems,  Brisbane,  5  Nov  98  [Online]  available  at  http://www.vtcorp.com/wma- 
incose/1997-docs/lakestds.ppt,  accessed  on  5  Nov  98. 
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^Technology  Australasia,  Standard  No  001,  Systems  Engineering,  Issue  3, 
(Melbourne:  Technology  Australasia,  20  September  1996),  ii. 
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CHAPTERS 


ORGANISATIONS  AND  THE  MATERIEL  CYCLE 
The  systems  development  methodology  that  this  study  develops  is  not  something 
fundamentally  new,  but  rather  a  procedure  for  applying  Systems  Engineering  within  the 
defence  context.  To  do  this  successfully,  the  relationship  between  Systems  Engineering, 
Integrated  Logistics  Support  (ILS),  Logistics  Support  Analysis  (LSA)  and  other  project 
management  methodologies  adopted  within  defence  must  be  stated  explicitly  for  it  to  be 
understood  and  accepted  by  the  relevant  authorities.  Furthermore  any  proposed 
methodology  must  be  placed  within  the  context  of  the  roles  of  the  various  organisations 
involved  in  the  relevant  phases  of  the  materiel  cycle.  This  raises  a  number  of  immediate 
questions. 

a.  What  are  the  organisations  involved  in  the  relevant  phases  of  the  materiel 
cycle? 

b.  What  are  the  phases  of  the  materiel  cycle? 

c.  What  is  the  relationship  between  Systems  Engineering,  ILS,  LSA,  and  other 
project  management  methodologies  within  defence? 

The  first  two  questions  will  be  dealt  with  in  this  chapter  and  the  last  question  will  be  dealt 
with  in  chapter  4. 

Defence  Organisations 

There  are  a  number  of  organisations  within  the  Australian  Defence  Force 
involved  in  the  development  and  fielding  of  a  new  capability  within  the  army.  Each  of 
these  organisations  could  use  a  systems  development  methodology,  to  some  extent,  in  the 
concept  and  acquisition  phases  of  the  army’s  materiel  cycle.  To  understand  the 
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application  of  a  systems  development  methodology,  it  is  first  necessary  to  identify  those 
organisations  that  would  be  involved  in  its  application. 

The  objective  of  the  Headquarters  Australian  Defence  Force  Headquarters 
(HQADF)  (Figure  2)  is  to  provide  for  the  higher  command  and  control  of  the  ADF  and 
give  advice  on  strategic  policy  and  long-term  Defence  planning,  the  management  of 
international  defence  relationships  and  the  development  of  defence  capabilities. 


HEADQUARTERS  AUSTRALIAN  DEFENCE  FORCE 


Figure  2.  Headquarters  Australian  Defence  Force  Organisational  Chart 


The  Strategic  Policy  Planning  Division  provides  defence’s  long  term  vision  and 
therefore  the  basis  for  the  early  stages  of  capability  development.  The  International 
Policy  Division  has  little  input  into  capability  development  but  the  Capability 
Programming  and  Resource  Planning  Division  (CPRP)  is  very  important.  The  CPRP 
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controls  the  initial  commitment  of  fimds  for  any  proposed  capability  and  therefore 
arguably  is  the  most  powerful  division  in  the  initial  stages  of  capability  development. 

The  Capability  Development  Division  is  responsible  for  representing  the  user  and 
developing  the  initial  capability  requirements. 

The  mission  of  the  newly  formed  National  Support  Division  (NSD)  is  to  broaden, 
shape  and  improve  National  and  International  Support  capabilities  and  arrangements  to 
better  enable  force  generation,  mobilization  and  sustainment  for  the  ADF.  As  a  result 
they  aim  to  comprehensively  engage  the  capability  development  process  to  the  extent  that 
their  input  is  seen  as  essential  to  the  presentation  of  balanced  capability  development 
proposals  to  the  decision  making  bodies.^  The  NSD  should  provide  critical  input  into  the 
systems  development  process. 

Neither  the  Strategic  Command  Division  nor  the  Australian  Theatre  Command  is 
directly  involved  in  capability  development. 

Divisions  within  HQADF 

The  Strategic  Policy  Planning  Division  (figure  3)  provides  the  long-term  vision 
for  defence.  Of  particular  relevance  to  the  very  early  stages  in  the  development  of  a 
capability  are  the  Capability  Programming  and  Plans  (CPP)  Branch,  which  determines 
the  defence  long  term  plan  and  the  Military  Strategy  Branch,  which  develops  strategic 
concepts. 
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Figure  3.  Strategic  Policy  Planning  Division  Organisational  Chart 


The  Capability  Programming  and  Resource  Planning  Division  (CPRP)  shown  in 
figure  4,  controls  the  initial  commitment  of  funds  for  major  capabilities.  The  head  of  the 
CPRP  Division,  HCPRP,  is  the  Chair  of  the  Capability  Forum  and  the  head  of  the 
Investment  Analysis  Program  (lAP)  Branch  acts  as  his  secretary.  The  lAP  branch 
therefore  prepares  the  agenda  for  the  Capability  Forum  and  writes  up  the  minutes  of  the 
meeting.  In  this  way  they  control  the  discussion,  the  issues  presented  and  the  official 
outcomes  of  the  meeting.  The  lAP  Branch  also  provides  the  issues  briefs  for  the  Defence 
Capability  Committee.  As  a  result  CPRP,  particularly  the  lAP  Branch,  is  perhaps  the 
most  powerful  and  therefore  most  important  player  in  the  early  development  phase  of  a 
capability. 


Figure  4.  Capability  Programming  and  Resource  Planning  Division 

Organisational  Chart 


The  Capability  Development  Division  (figure  5)  is  responsible  for  sponsoring  all 
ADF  Options  Papers  and  developing  Issues  Papers  dealing  with  the  acquisition  of  capital 
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equipment.  They  work  with  CPRP  in  the  development  of  these  documents.  As  the 
official  capability  project  sponsor,  they  have  responsibilities  in  the  concept  and  definition 
stages,  and  after  Government  approval  of  a  project.  They  are  also  responsible  for 
formulating  operational  requirements  for  each  capability.  They  represent  the  user 
community  and  develop  the  initial  capability  requirements.  As  the  project  sponsor,  the 
Capability  Development  Division  is  a  key  player  in  the  early  stages  of  the  materiel  cycle. 


Figure  5.  Capability  Development  Division  Organisational  Chart 


The  division  has  three  branches  that  represent  the  three  services  and  one  branch 
that  deals  with  command,  control,  communications  and  intelligence  (C3I)  across  all 
services.  Of  most  relevance  to  the  development  of  army  capabilities  is  the  Land 
Development  Branch,  which  deals  with  army  capabilities.  One  should  note  however  that 
capability  requirements  might  come  fi-om  the  other  branches,  particularly  if  it  is  an  army 
equipment  that  must  operate  with  the  other  services.  Joint  Project  1 17  (JPl  17)  which 
seeks  to  procure  groimd  based  air  defence  weapon  systems  for  the  Australian  Army  has  a 
number  of  important  requirements  generated  by  the  Aerospace  Development  Branch 
relating  to  interoperability  with  the  Royal  Australian  Airforce  (RAAF).  As 
interoperability  vdth  the  Navy  and  the  C3I  aspects  of  integration  into  the  Australian  Air 
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Defence  picture  are  important,  requirements  may  also  be  generated  in  the  Maritime  and 
C3I  branches. 

Defence  Acquisition  Organisation 

The  Australian  Defence  Acquisition  Organization  (DAO)  (figure  6)  is  not  part  of 
HQADF.  It  acquires  equipment  and  systems,  and  promotes  the  industry  support  that 
underpins  Australia's  Defence  capability.  It  therefore  manages  major  projects  while 
minor  projects  are  managed  by  Support  Command.  The  baseline  that  generally 
distinguishes  a  major  capital  equipment  project  from  a  minor  one  is  a  budget  of  AS$20 
million  dollars  or  more. 


Figure  6.  Defence  Acquisition  Organisation  Organisational  Chart 


The  DAO  is  made  up  of  a  number  of  divisions.  It  initially  had  a  cell  responsible 
for  implementing  government  reforms  arising  fi-om  the  Defence  Restructuring  Program. 
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The  Capital  Equipment  Program  Division  provides  the  corporate  management  and 
acquisition  finance  and  reporting  functions.  It  also  provides  acquisition  planning  and 
advice  to  the  Deputy  Secretary  on  source  selection.  The  Industry  Procurement  and 
Infrastructure  Division  deals  with  industry,  contract  and  export  policy.  It  deals  with  how 
industry  gets  involved  with  a  particular  acquisition  project,  and  works  closely  with  the 
acquisition  Project  Offices  in  the  Systems  Acquisition  Divisions.  The  Systems 
Acquisition  Divisions  are  organized  along  technological  and  not  service  lines.  While 
most  major  army  projects  may  reside  within  the  Maritime  and  Ground  Division,  major 
army  projects  are  also  managed  within  the  Electronics  and  Aerospace  divisions.  It  is  in 
the  Systems  Acquisition  Divisions  that  the  project  management  and  the  bulk  of  the 
system  development  work  for  major  projects  are  traditionally  done. 

Support  Command  (figure  7)  is  primarily  responsible  for  in-service  management. 
However,  as  the  Army’s  principle  element  within  Support  Command,  Support 
Commander  Army  is  responsible  for  the  management  of  army’s  minor  projects  and  is 
also  involved  in  the  acquisition  phase. 

The  final  organisation  that  is  important  to  the  development  of  a  capability  in  the 
concept  and  acquisition  phases  is  the  Combined  Arms  Training  and  Development  Centre 
(CATDC).  This  is  an  Army  unit  that  assists  in  the  development  of  capability 
requirements.  It  analyses  the  doctrine,  equipment,  organisation  and  training  options  to 
meet  a  capability  requirement.  It  also  develops  and  promulgates  doctrine,  imdertakes 
warfighting  experiments  to  test  options,  and  develops  and  adapts  training  to  support  new 
capabilities. 
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Figure  7.  Support  Command  Organisational  Chart 


The  Defence  Materiel  Cycle-Cradle  to  Grave 
The  Australian  Defence  Force  materiel  cycle  is  shown  in  figure  8.  It  covers  the 
entire  life  cycle  of  a  capability  from  the  first  identification  of  a  need  through  to  the  final 
disposal.  The  cycle  has  four  phases  and  could  cover  a  period  in  the  order  of  sixty  to 
seventy  years  for  a  major  weapons  system.  They  are  the  concept,  acquisition,  in-service 
and  disposal  phases. 

The  materiel  cycle  starts  in  the  concept  phase.  The  complete  cycle  first 

encompasses  need  identification,  project  definition,  conceptual  design  and  project 

development  and  preliminary  design.  Detailed  design  and  development  is  conducted 
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before  the  equipment  is  produced.  It  is  then  tested  for  acceptance  by  the  sponsoring 
authority  before  being  brought  into  service  and  supported.  It  is  finally  disposed  of  once  it 
reaches  its  life-of-type. 


Figure  8.  Defence  Materiel  Cycle 


The  materiel  cycle  relates  to  equipment  solutions  to  capability  needs.  This  does 
not  however  mean  that  the  answer  to  a  particular  capability  requirement  will  always  be  an 
equipment  solution.  Military  capability  is  a  combination  of  force  structure  and 
preparedness,  while  force  structure  is  comprised  of  the  organisation,  facilities,  workforce, 
equipment  and  doctrine  of  the  ADF.  The  solution  to  a  particular  capability  need  could 
generate  a  range  of  options  apart  from  any  consideration  of  an  equipment  solution.  Only 
if  die  non-materiel  solutions  are  found  to  be  unsatisfactory  should  a  materiel  solution  be 
pursued. 
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This  study  deals  with  the  application  of  a  systems  development  methodology  to 
materiel  solutions.  However,  the  methodology  is  equally  applicable  to  non-materiel 
solutions  although  it  might  then  be  applied  in  a  less  rigorous  form. 

Materiel  Cycle  Phases 

The  concept  phase  starts  with  the  identification  of  the  need  for  a  new  capability 
through  the  force  development  process.  It  ends  with  the  formal  government  approval  to 
acquire  the  capability.  The  major  players  in  this  phase  are  the  Combined  Arms  Training 
and  Development  Centre  (CATDC),  Capability  Development  Division  (CD  Div), 
specifically  Land  Development  Branch;  the  Capability  Programming  and  Resource 
Planning  Division  (CPRP)  and  to  a  much  lesser  extent  the  Defence  Acquisition 
Organisation  (DAO).  In  the  case  of  minor  projects  Support  Command  may  be  involved. 
Close  liaison  between  the  project  sponsor,  the  project  office  (if  established)  and  other 
agencies,  is  required.  Products  that  are  developed  during  this  phase  include  feasibility 
studies,  an  operational  concept  document  and  mission  profile,  initial  cost  and/or 
capability  analysis.  Front  End  Logistic  Support  Analysis  (FELSA)  and  a  logistic  support 
concept,  military  options  papers,  options  papers  and  issues  papers.  For  a  major  project 
this  phase  is  normally  about  one  to  two  years,  although  depending  on  the  political 
sensitivity  or  budgetary  implications  of  the  project  it  could  take  significantly  longer.  It  is 
in  this  phase  that  the  initial  requirements  for  the  capability  are  specified  and  cost 
estimates  are  produced  as  a  baseline  for  the  acquisition  phase.  It  is  therefore  essential 
that  an  appropriate  systems  development  methodology  be  applied  during  this  phase  to 
ensure  that  the  capability  definition  and  cost  estimates  are  of  sufficient  fidelity  and 
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quality  to  provide  a  useful  baseline  for  the  acquisition  phase.  Traditionally  this  has  not 
been  the  case. 

The  acquisition  phase  starts  with  government  approval  to  acquire  a  specified 
capability  and  ends  with  the  capability’s  acceptance  into  service.  The  major  player  in 
this  phase  is  the  Defence  Acquisition  Organisation  (DAO)  for  major  projects  and  Support 
Command  for  minor  projects.  The  respective  project  offices  have  responsibility  for 
managing  the  project  in  this  phase.  Close  liaison  should  be  maintained  with  the  project 
sponsor  until  they  accept  the  capability  into  service.  Other  organisations  that  may  be 
closely  involved  are  the  Defence  Science  and  Technology  Organisation,  the  Maintenance 
Engineering  Agency,  the  Army  Technical  Engineering  Agency  and  Support  Command, 
for  in-service  support  planning  issues.  The  Industry  Procurement  and  Infrastructure 
Division  supports  the  major  project  offices  on  industry  matters  during  acquisition.  In  this 
phase  the  system  design  activities  are  conducted.  These  include  specification 
development,  contracting,  production,  ILS  and  LSA,  project  management,  quality 
assurance,  test,  evaluation,  and  acceptance.  It  is  in  this  phase  that  the  systems 
requirements  developed  in  the  concept  phase  are  converted  into  a  systems  specification 
and  most  of  the  detailed  parameters  of  the  system  are  set.  It  is  therefore  essential  that  an 
appropriate  systems  development  methodology  is  used  during  this  phase. 

The  in-service  phase  starts  with  the  transfer  of  responsibility  for  the  capability 
from  the  project  office  to  the  user,  and  ends  with  the  disposal  of  the  capability.  While 
this  phase  may  include  some  refinement  to  the  logistic  support  plans,  mission  profiles  and 
system  specifications,  it  is  generally  very  costly  to  do  so.  It  is  therefore  important  that 
these  issues  are  resolved  as  much  as  possible  prior  to  the  system  being  brought  into 
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service.  Dxiring  this  phase  the  equipment  is  operated  by  the  user  and  sustained  through 
logistic  support.  Equipment  and  personnel  training  is  conducted  and  data  are  collected 
and  analyzed  as  part  of  the  continuous  feedback  process  to  increase  systems 
effectiveness. 

The  disposal  phase  includes  the  reduced  operation  and  phasing  out  of  a  capability. 
This  may  include  recycling,  disposal  or  resale.  The  removal  of  dangerous  waste  and 
materiels,  and  the  financial  and  resources  costs  of  disposal  should  be  considered  as  early 
as  possible  in  the  materiel  cycle. 

Defence  Procurement  Process 

The  defence  procurement  process  (figure  9)  occurs  across  the  entire  materiel 
cycle.  The  funnel  shape  in  figure  9^  reflects  the  refinement  of  ideas  throughout  this 
process.  The  Australian  Defence  Headquarters  is  responsible  for  the  strategic  planning 
and  capability  development  stages,  under  the  Head  of  Strategic  Policy  and  Plans  and  the 
Head  of  Capability  Development  respectively.  Responsibility  is  then  passed  to  the 
Deputy  Secretary  Acquisition  whose  Defence  Acquisition  Organization  manages  the 
acquisition  of  systems  to  meet  the  defined  capability.  Once  a  system  has  been  acquired 
and  brought  into  service,  responsibility  transfers  to  the  user  services  (Navy,  Army,  Air 
Force)  or  Joint  Service  entities,  for  operation  and  through  life  support.  This  support  is 
managed  through  Support  Command  Australia. 

The  stages  in  the  procurement  process  are  not  entirely  discrete  however,  and  there 
are  a  number  of  overlaps.  For  example  the  DAO  is  almost  always  required  to  further 
develop  the  capability  requirement  given  to  it  by  the  Capability  Division  before  it  can 
release  a  tender  to  industry  to  acquire  a  particular  capability.  Use  of  an  effective  systems 
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development  methodology  by  Capability  Division  would  reduce  the  amoxmt  of  work  that 
needs  to  be  done  at  the  transition  to  the  acquisition  stage. 

The  feedback  loops  in  figure  9,  indicate  the  requirement  for  continuous  appraisal 
of,  and  timely  reaction  to,  changes  in  strategic,  operational  and  tactical  environments, 
technology  advances  and  other  factors  that  impinge  on  capability.'* 


Feedback 


Capability  Development  Process 

The  capability  development  process  (figure  10)  has  a  number  of  key  documents. 
The  process  starts  with  the  Australian  Government’s  strategic  guidance.  This  provides 
the  basis  for  the  ADF’s  development  planning.  The  major  sources  of  strategic  guidance 
are  the  Defence  White  Papers  and  strategic  basis  papers.  The  Combined  Arms  Training 
and  Development  Centre  will  develop  papers  on  military  capability  options  and  provide 
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them  to  the  Land  Development  Branch  of  the  Capability  Development  Division  who  then 
produce  Military  Options  Papers.  It  is  therefore  important  that  a  systems  development 
methodology  be  applied  within  the  Combined  Arms  Training  and  Development  Centre 
and  carried  through  to  the  Land  Development  Branch. 
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Figure  10.  Key  Capability  Development  Products  in  the 
Concept  and  Acquisition  Phases 


The  Defence  Long  Term  Plan  (DLTP)  which  looks  out  20-25years,  and  the 
Defence  Medium  Term  Plan  (DMTP)  which  looks  out  5-10  years  are  developed  by  the 
Strategic  Policy  Planning  Division.  The  Pink  Book  contains  the  authorized  program  of 
unapproved  major  capital  equipment  proposals.  The  Options  Papers  and  Issues  Papers 
are  developed  within  the  Capability  Development  Division  and  the  Capability 
Programming  and  Resource  Planning  Division  with  occasional  assistance  requested  from 
the  DAO.  The  papers  are  created  for  committee  consideration. 

System  Design  includes  all  of  the  activities  that  the  acquisition  organisation 
completes  to  produce  systems  specification  and  Request  for  Tender  documentation.  The 
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Request  for  Tender  is  given  to  industry  and  tender  evaluation  is  conducted  on  the  offers 
received.  The  Commonwealth  then  acquires  a  complete  system,  which  results  in  a 
capability  being  introduced  into  service. 

The  key  conunittees  in  the  capability  development  process  are  the  Capability 
Forum  and  the  Defence  Capability  Committee  (DCC).  The  role  of  the  Capability  Forum 
is  to  make  capability  development  decisions  on  issues  and  aspects  delegated  by  the  DCC, 
including  less  significant  and  less  costly  proposals,  early  definition  phases  of  more 
significant  proposals,  and  details  arising  from  broad  decisions  on  more  significant 
proposals.  It  also  gives  recommendations  to  the  DCC  on  the  level  of  investment  in  less 
significant  proposals  for  the  aimual  program.  The  decisions  from  the  Capability  Forum 
should  provide  the  basis  of  the  submission  seeking  government  approval  to  begin  the 
acquisition  phase.  These  should  also  provide  sufficient  detail  on  the  cost/capability 
tradeoffs  for  the  armual  programming  meeting  of  the  DCC.  ^  This  means  that  the  input  to 
the  Capability  Forum  should  be  sufficiently  rigorous  and  properly  formatted  to  achieve 
this.  The  application  of  a  systems  development  methodology  will  directly  affect  the 
inputs  to  this  committee.  As  a  result,  the  members  of  the  Capability  Forum  will  have  a 
key  stake  in  the  methodology’s  application  and  the  nature  of  its  outputs. 

The  key  personnel  on  the  Capability  Forum  are  the  chair,  who  is  the  head  of  the 
Capability  Programming  and  Resource  Planning  Division  and  the  members,  who  are  the 
Head  of  the  Capability  Development  Division  and  the  First  Assistant  Secretary  Capital 
Equipment  Program.  Invited  members  include  the  deputy  chiefs  of  the  three  services  and 
various  departmental  heads. 


37 


The  role  of  the  DCC  is  to  make  key  decisions  on  capability  development.  It  is 
also  to  recommend  to  the  Defence  Management  Committee  the  annual  program  of 
investment  to  be  made  in  capability,  and  it  is  to  manage  the  process  of  getting  lower  level 
capability  development  decisions  made.  Therefore,  the  DCC  will  also  dictate  the  form 
and  nature  of  the  systems  development  outputs. 

The  key  personnel  on  the  DCC  are  the  chair,  the  Deputy  Secretary  Strategy  and 
Intelligence  (DEPSEC  S&I)  and  the  members,  the  Vice  Chief  of  the  Defence  Force 
(V CDF)  and  the  Deputy  Secretary  Acquisition  (DEPSEC  A).  Invited  members  include 
the  chiefs  of  the  various  services. 

The  Defence  Source  Selection  Board  (DSSB)  endorses  a  major  project’s 
Equipment  Acquisition  Strategy  (EAS)  and  recommends  to  DEPSEC-A  the  preferred 
source  of  supply.  Because  the  DSSB  deals  with  predominantly  project  management  and 
contractual  issues  it  does  not  become  involved  with  the  application  of  the  systems 
development  methodology.  It  is  therefore  not  discussed  further  in  this  study. 

As  stated  earlier,  the  proposed  systems  development  methodology  to  be  applied  to 
the  concept  and  acquisition  phases  of  the  materiel  cycle  is  simply  a  method  of  applying 
Systems  Engineering  within  the  defence  context.  The  relationship  between  Systems 
Engineering,  ILS,  LSA,  and  other  project  management  methodologies  adopted  within 
Defence  must  therefore  be  understood.  Chapter  4  examines  each  of  these  elements  and 
their  relationship. 

*  Australian  Department  of  Defence,  National  Support  Division— Key  Result  Areas 
and  Goals,  KRA  2  Goal  3,  accessed  5  Feb  99;  available  from 
http://www.defence.gov.aU/NSD/f  goals.htm;  Internet. 
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^Australian  Department  of  Defence,  Major  Capital  Equipment  Acquisition 
Process,  (Canberra:  TLM/Kinhill,  13-17  October  1997),  Session  PMC02, 4-8. 

^Rear  Admiral  D.  Shackleton,  Establishing  the  Capability  Development  Advisory 
Forum,  Discussion  Paper,  (Australian  Defence  Headquarters,  Canberra  ACT:  Australian 
Defence  Force,  1  Dec  98),  14. 

^Ibid.,  14, 15. 

^Australian  Department  of  Defence,  Project  Management  Education  and  Training 
Notes,  Session  PMC40, 11-13. 
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CHAPTER  4 


SYSTEMS  DEVELOPMENT  PROCESS 

This  chapter  outlines  a  systems  development  methodology.  This  methodology  is 
an  application  of  an  integrated  approach  to  Systems  Engineering,  Integrated  Logistics 
Support  (ILS)  and  Logistics  Support  Analysis  (LSA)  within  the  defence  context.  To  do 
this  successfully  it  is  necessary  to  understand  the  relationship  between  Systems 
Engineering,  ILS,  LSA,  and  other  project  management  methodologies  adopted  within 
defence. 

This  chapter  first  examines  the  Systems  Engineering,  ILS  and  project 
management  disciplines  separately,  and  then  outlines  how  they  can  be  integrated  Avithin 
the  Army  to  ensure  that  a  systems  approach  is  applied  to  the  concept  and  acquisition 
phases  of  the  materiel  cycle. 

Systems  Engineering 

Effective  capability  development  is  important  to  the  warfighter  because  it  directly 
affects  their  ability  to  prosecute  war.  If  the  requirements  for  a  new  system  are 
inadequately  defined  the  warfighter’s  needs  will  not  be  met.  After  an  equipment  is 
introduced  into  service  they  may  find  that  it  does  not  do  what  they  want  it  to  do:  they 
cannot  fight  with  it  because  it  does  not  meet  their  concept  of  operations;  they  do  not  have 
the  resources  to  support  it;  and  it  imposes  an  additional  maintenance  burden  on  them.  If 
the  system  requirements  are  unnecessarily  over-specified  the  system  may  increase  in  cost 
which  means  that  they  either  receive  less  of  that  equipment  or  less  of  another  required 
capability. 


40 


The  Australian  Department  of  Defence  has  a  history  of  project  cost  and  schedule 
overruns  in  developing  and  acquiring  new  capabilities,  as  shown  in  appendix  A.  The 
method  of  developing  and  acquiring  capability  must  be  improved.  One  discipline  that 
may  be  used  to  achieve  this  is  Systems  Engineering. 

The  goal  of  Systems  Engineering  is  to  completely  and  correctly  identify  and 
validate  the  requirements  that  apply  to  a  capability  and  to  transform  them  into  a 
description  of  system  elements  that  best  satisfy  these  requirements.  It  aims  to  achieve 
these  goals  at  a  cost  equal  to  or  better  than  budget  and  in  a  total  time  equal  to  or  better 
than  schedule.* 

The  US  mandates  that  a  Systems  Engineering  approach  be  used  to  translate 
operational  needs  and/or  requirements  into  a  systems  solution.  DOD  5000.2-R  requires 
that  the  Systems  Engineering  process  be  used  to  establish,  “a  proper  balance  between, 
risk,  cost,  and  schedule,  employing  a  top-down  iterative  process  of  requirements  analysis, 
functional  analysis  and  allocation,  design  synthesis  and  verification,  and  system  analysis 
and  control.”^ 

This  is  consistent  with  the  Systems  Engineering  process  as  defined  in  EIA 
Standard  IS  -632,  which  is  made  up  of  foiur  key  activities.  They  are: 

a.  Requirements  Analysis; 

b.  Functional  Analysis/Allocation; 

c.  Synthesis;  and 

d.  Systems  Analysis  and  Control. 

The  Systems  Engineering  Process  is  outlined  in  figure  11.^ 


INITIAL  PROCESS  INPUT 


FINAL  PROCESS  OUTPUT 


Figure  1 1 .  Systems  Engineering  Process 
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There  are  a  number  of  inputs  to  the  Systems  Engineering  process  within  defence.  These 
include  the  user  needs,  objectives  and  requirements  represented  in  strategic  guidance, 
military  option  papers,  and  option  and  issue  papers.  Capability  concept  of  operations  and 
mission  profiles  are  also  incorporated  as  a  capability  becomes  better  defined.  The 
constraints  placed  on  the  capability,  the  environment  in  which  it  must  operate,  and  the 
measures  of  effectiveness  required  by  various  reviewing  bodies  must  be  identified  and 
entered  into  the  process.  Other  inputs  include  the  existing  technology  base,  any  prior 
output  data  such  as  use  studies,  and  financial  or  programming  constraints.  Furthermore 
any  process  that  is  applied  within  defence  must  account  for  government  and  internal 
political  requirements. 

The  output  from  the  process  is  a  balanced  system  solution  and  an  integrated 
decision  database.  This  database  would  include  system  functional  and  physical 
architectures,  specifications  and  baselines  and  decision  support  data.  These  data  are 
developed  throughout  the  process  to  an  increasing  level  of  definition.  They  support  the 
decision  making  process  of  review  groups  and  committees  such  as  the  Capabilities  Forum 
and  the  Defence  Capabilities  Committee.  Key  decision  support  data  include 
cost/capability  options  and  credible  life  cycle  cost  estimates.  Such  data  are  essential  for 
informed  decision  making  at  the  committee  level  and  significantly  reduce  the  risk  of 
project  cost  overruns  in  the  acquisition  and  in-service  phases  of  the  materiel  cycle.  Some 
of  the  major  products  of  Systems  Engineering  include: 

a.  System  Specification, 

b.  Test  Plans, 

c.  Integration  Plans, 
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d.  Trade  Study  Reports, 

e.  Configuration  Management  Plan, 

f.  Requirements  Database, 

g.  Life  Cycle  Cost  Reports, 

h.  Systems  Engineering  Management  Plan,  and 

i.  Interface  Control  Documents. 

Requirements  Analysis 

Requirements  analysis  is  the  activity  that  considers  customer  needs,  objectives, 
and  requirements  to  determine  the  functional  and  physical  standard  for  each  primary 
system  function.  In  the  defence  context,  these  eventually  translate  into  a  number  of  key 
documents  including  a  system  specification,  which  is  given  to  industry  in  the  acquisition 
phase.  Requirements  analysis  is  conducted  within  the  context  of  the  capability’s  mission 
and  operating  environment,  its  use  and  any  predetermined  system  characteristics.  Prior 
analyses  are  reviewed  and  updated  and  mission/operational  and  environmental  definitions 
are  refined.  The  operating  environment  is  examined  to  determine  the  context  within 
which  the  system  is  to  operate,  and  the  boundary  between  the  system  and  the  outside 
environment.  A  traceable  top  down  hierarchy  of  requirements  is  produced  during  this 
stage.  Figure  12  shows  an  example  of  a  top  down  requirements  hierarchy. 

Requirements  may  include  physical,  interface,  environmental,  resource, 
functional  or  performance  characteristics.  Physical  requirements  relate  to  the  physical 
properties  of  the  system.  Interface  and  environmental  requirements  deal  with  how  the 
system  interacts  with  the  outside  environment.  Resource  requirements  deal  with  what 
resources  the  system  consumes,  for  example,  ammunition.  Functional  requirements  state 
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what  the  system  is  to  do  and  performance  requirements  state  how  well  the  system  is  to  do 
it. 

In  accordance  with  EIA  Standard  IS-632,  the  requirements  validation  process 
establishes  an  upward  and  downward  traceability  of  requirements  that  result  from  the 
inputs  to  the  Systems  Engineering  process.  This  ensures  that  each  lower  level 
requirement  comes  from  a  higher  level  one.  It  is  essential  that  requirements  traceability 
is  maintained  as  the  requirements  gain  greater  definition  whilst  in  the  concept  and 
acquisition  phases  of  the  materiel  cycle. 

This  requirements  hierarchy  not  only  provides  a  baseline  against  which  the 
functional  requirements  of  the  system  are  developed  but  provides  visibility  and 
justification  for  each  requirement  listed.  This  is  particularly  important  when  the 
Organisations  managing  the  development  of  a  capability  appear  before  review  groups  and 
committees.  The  impact  of  removing  and  changing  requirements  can  be  clearly 
demonstrated  and  tracked.  For  example,  if  a  committee  Avished  to  remove  requirement 
2.2.2  (figure  12),  then  it  could  be  clearly  demonstrated  that  the  capability  would  no 
longer  be  able  to  meet  requirement  2.2  and  its  ability  to  meet  requirement  2.0  would  be 
significantly  affected.  It  would  also  highlight  that  requirements  2.2.2. 1, 2.2.2.2  and  their 
lower  level  requirements  would  no  longer  be  needed,  thus  avoiding  producing  a 
capability  against  invalid  and  unnecessary  requirements. 

The  benefits  of  requirements  analysis  are  that  it: 

a.  assists  in  refining  customer  objectives  and  requirements; 

b.  defines  the  problem  by  identifying  the  objectives  for  the  capability  and  refines 

them  into  requirements; 
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c.  identifies  and  defines  the  constraints  on  possible  solutions  (for  example, 
manpower  ceilings,  budgetary  limitations,  environmental  considerations) 

d.  defines  the  functional  and  performance  requirements  based  on  the  required 
measures  of  effectiveness.  If  measures  of  effectiveness  have  not  been  provided  in 
sufficient  detail,  then  they  are  developed  during  this  stage.'* 

Functional  Analysis/Allocation. 

Functional  analysis  and/or  allocation  is  the  activity  that  determines  the  detailed 
functions  the  capability  must  perform.  It  defines  and  integrates  a  functional  architecture 
to  the  level  of  detail  needed  to  support  the  production  of  solutions  in  the  synthesis  stage 
of  the  Systems  Engineering  process.  Functional  analysis  and/or  allocation  is  a  method 
for  analyzing  performance  requirements  and  decomposing  them  into  discrete  tasks  or 
activities.  This  functional  decomposition  is  conducted  iteratively  both  to  develop  lower 
level  functions  based  on  higher  level  functional  requirements  and  to  ensure  that 
performance  requirements  and  design  constraints  flow  down.^ 

A  function  is  “a  characteristic  action  to  be  accomplished  by  one  of  the  system 
elements  of  hardware,  software,  facilities,  personnel  data,  or  any  combination  thereof”® 
The  decomposition  of  a  system  can  be  viewed  as  a  top-down  approach  to  problem 
solving.  It  results  in  a  hierarchical  tree  structure,  which  progressively  divides  and 
allocates  requirements  until  the  lowest  level  function  that  meets  a  definable  requirement 
is  reached. 

The  opposite  approach  is  a  bottom-up  method  that  is  easier  to  apply  to  situations 
where  a  number  of  existing  components,  with  well-defined  capabilities  are  combined  to 
meet  the  system  objectives.  Due  to  budget  and  schedule  constraints,  this  approach  more 
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closely  represents  the  real  world.  However,  due  to  interface  and  interoperability  issues 
that  exist  even  with  nondevelopmental  projects,  this  approach  may  be  difficult  to 
implement.  In  practice,  a  combination  of  both  the  top-down  and  bottom-up  approaches  is 
used. 


Requirements  Hierarchy 


jSt 

Level 


2nd 

Level 


3rd 

Level 


Figure  12.  Requirements  Hierarchy 


Functional  analysis  is  conducted  iteratively  and  in  parallel  with  requirements 
analysis  so  that  the  elements  of  the  requirements  hierarchy  relate  directly  to  the 
developing  fimctional  requirements,  and  higher  level  requirements  are  met  (figure  13). 
This  maintains  consistency  between  requirements  and  design.  It  is  performed  iteratively 
with  the  synthesis  stage  of  the  Systems  Engineering  process  to  define  and  refine 
workable  solution  alternatives  that  meet  the  stated  requirements. 
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Requirements  Hierarchy  ,  Functional  Hierarchy 


Figure  13.  Requirements  and  Functional  Hierarchies 


The  relationship  between  requirements  and  functions  is  not  necessarily  one  to 
one.  Each  requirement  may  generate  a  number  of  different  required  functions,  for 
example  there  may  be  a  requirement  for  a  communications  control  system  that  is  capable 
of  switching  both  local  and  transit  traffic.  Some  derived  functions  for  part  of  the  system 
could  be  “send  signal”  and  “receive  signal.” 

A  functional  architecture  (figure  14)  is  developed  from  a  functional  hierarchy 
(figure  13).  A  functional  architecture  views  the  system  as  a  network  of  interfacing 
functions.  It  shows  the  relationship  between  the  various  functions,  the  inputs  and  outputs 
and  the  sequence  of  operation  of  the  functions  to  achieve  a  particular  result. 

Synthesis 

The  S5mthesis  activity  produces  solutions  for  each  set  of  functional  and 
performance  requirements  in  the  functional  architecture.  These  solutions  are  called 
physical  architectures.  A  physical  architecture  is  an  arrangement  of  the  hardware, 
software,  facilities,  personnel  and  other  components  that  make  up  a  system  (figure  15).^ 

It  shows  the  relationship  between  the  physical  components  of  the  system  and  the  major 
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functional,  performance  and  other  requirements  of  each  component  of  the  system.*  As  a 
rule  the  army  will  not  get  involved  in  designing  and  building  its  own  equipment  and 
prefers  “nondevelopmental”  items.  Therefore  it  is  not  intended  that  these  physical 
architecture  options  be  built  by  defence.  However,  they  provide  the  basis  for 
cost/capability  analysis  and  logistics  modeling. 

Major  committees  generally  do  not  have  the  time  or  inclination  to  examine 
abstract  requirements  or  functional  architectures  in  detail  and  prefer  their  data  in  a  simple 
and  easily  understandable  form.  As  a  result,  the  physical  architecture  options  are  likely 
to  be  among  the  key  products  that  are  presented  to  these  reviewing  bodies. 


Figure  14.  Fimctional  Architecture 


Synthesis  is  conducted  interactively  with  functional  analysis  and/or  allocation  and 
requirements  analysis.  The  outputs  must  describe  the  complete  system,  including  internal 
and  external  interfaces  and  relationships. 
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Figure  15.  Physical  Architecture  Example 


The  Synthesis  activity: 

a.  determines  whether  the  functional  and  performance  requirements  are  complete 
and  derives  additional  requirements; 

b.  defines  sets  of  functions  and  allocates  them  to  parts  of  the  system  being 
specified; 

c.  defines  and  integrates  any  internal  or  external  physical  interfaces; 

d.  identifies  and  analyses  critical  parameters; 

e.  defines  alternatives  in  terms  of  hardware,  software,  people,  and  processes; 

f.  defines  system,  subsystem,  and  system  element  solutions  to  a  level  of 
definition  required  for  the  production  of  a  functional  system  specification; 
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g.  translates  the  architecture  selected  from  the  cost/capability  analysis  into  a 
specification  tree,  specifications,  configuration  baselines  and  a  work  breakdown 
structure,  as  required.^ 

Figure  16  shows  the  process  flow  for  the  Synthesis  activity.  It  shows  the 
relationship  between  functional  hierarchies,  functional  architectures  and  physical 
architectures. 

Synthesis  Activity- Application  of  Design.  The  synthesis  activity  designs 
solutions  for  each  set  of  functional  and  physical  requirements.  The  design  activity 
detailed  in  El  A  Standard  IS-632  must  be  significantly  tailored  for  application  to  the 
Army.  The  design  activity  as  it  will  normally  be  applied  within  the  Army  relates 
primarily  to  the  design  and  development  tendering  of  documentation.  The  primary 
document  produced  is  the  system  specification.  As  applied  to  the  Army,  the  design 
activity  develops: 

a.  the  information  for  establishing  and  updating  applicable  functional,  allocated, 
and  product  baselines  as  required; 

b.  system,  lower-level  item,  process,  and  materiel  specifications  including 
commercial  item  requirements; 

c.  interface  control  requirements; 

d.  life  cycle  resource  requirements;  and 

e.  procedural  handbooks  and  instructional  materiel  requirements. 

Synthesis  Activity— Application  within  Defence.  It  is  important  to  realize  the 

manner  in  which  the  synthesis  activity  is  to  be  applied  within  defence.  The  synthesis 
activity  as  detailed  in  EIA  Standard  IS-632  is  described  in  terms  applicable  for  its  use  by 
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Functional  Hierarchies 


Physical  Architectures 


Option  1 
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Figure  16.  Synthesis  Process 
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organisations  conducting  new  systems  development,  upgrades,  modifications  and  the 
technical  efforts  required  in  preparation  to  responses  to  solicitations.  However  for  the 
Army,  in  the  concept  and  acquisition  phases  of  the  materiel  cycle,  these  tasks  are  the 
responsibility  of  industry.  This  does  not  make  the  synthesis  activity  any  less  relevant  to 
defence.  The  activity  must  be  tailored  to  meet  defence’s  needs. 

In  defence’s  case,  the  synthesis  activity  is  conducted  to  assist  in  the  production  of 
generic  physical  architecture  options  that  are  used  in  cost  and/or  capability  analyses  and 
act  as  benchmarks  for  LSA  activities.  The  synthesis  activity  also  directly  supports 
requirements  analysis  and  the  determination  and  allocation  of  functional  and  performance 
requirements  necessary  for  the  production  of  a  complete  systems  specification. 

Where  the  likely  physical  solution  is  a  nondevelopmental  item,  the  synthesis 
activity  ensures  that  the  characteristics  of  the  nondevelopmental  item  fit  within  the 
characteristics  defined  by  system  requirements.  It  is  not  often  the  case  that  a  solution  will 
be  entirely  nondevelopmental  and  require  no  integration.  It  is  more  likely  that  the 
possible  solutions  will  be  assembled  from  a  set  of  elements,  of  which  one  or  more  is  a 
non-developmental  item.  In  this  case,  the  synthesis  activity  ensures  that  the 
characteristics  of  the  nondevelopmental  item  fit  within  both  the  system  characteristics 
defined  for  that  specific  element  and  the  overall  related  systems  requirements. 

Materiel  Solution  Determination.  There  is  a  danger  that  the  physical  architecture 
options  may  be  used  inappropriately.  The  Systems  Engineering  process  assists  defence 
in  better  defining  its  requirements.  This  may  narrow  the  field  of  materiel  solutions, 
thereby  saving  industry  and  government  time  and  money.  However  committees  should 
not  use  the  physical  architecture  options  as  the  basis  for  predetermining  materiel 


53 


solutions.  It  should  remain  the  role  of  industry  to  present  materiel  solutions  to  the 
government  as  part  of  a  tendering  process  against  a  properly  detailed  system 
specification.  It  is  against  these  responses  that  final  materiel  solution  decisions  should  be 
made.  It  is  important  that  industry  be  allowed  to  present  their  solutions  to  defence’s 
requirements  without  a  specific  materiel  solution  having  already  been  predetermined. 

Physical  architecture  options  are  used  throughout  the  Systems  Engineering 
process  to  provide  clarity,  visibility,  and  definition  as  the  system  is  developed.  They 
establish  the  feasibility  of  physically  realizing  the  functional  architecture  and  provide  an 
input  to  effectiveness  analysis.  This  analysis  results  in  the  selection  of  at  least  one 
physical  architecture  to  be  carried  forward  for  further  detailed  design.  Physical 
architecture  options  are  not  to  be  used  for  prematurely  determining  specific  materiel 
solutions. 

Systems  Analysis  and  Control 

The  systems  analysis  and  control  activity  measures  progress,  evaluates 
alternatives,  selects  preferred  alternatives,  and  documents  data  and  decisions.  Systems 
analyses  are  conducted,  including  trade-off  studies  and  effectiveness,  cost/capability  and 
design  analyses.  Control  mechanisms  include  the  use  of  risk,  configuration,  interface, 
and  data  management,  and  the  application  of  performance  based  measures  specific  to  a 
particular  capability. 

Systems  analysis  and  control  aims  to  ensure  that- 

a.  decisions  on  solution  alternatives  are  made  on  the  basis  of  the  entire  system. 

This  includes  the  impact  on  system  effectiveness,  life  cycle  cost  and  resource 

requirements,  risk  and  user  requirements; 
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b.  traceability  is  maintained  throughout  the  whole  process; 

c.  technical,  logistic  and  supporting  disciplines  are  integrated  into  the  Systems 
Engineering  effort; 

d.  the  impact  of  user  requirements  is  examined  for  validity,  consistency, 
desirability  and  attainability  with  respect  to  available  resources,  life-cycle  costs, 
risks,  regulations,  and  other  identified  constraints  and  limitations.  The  level  of 
existing  and  emerging  technology  must  be  examined  to  ensure  that  the  developing 
requirements  are  reasonable  and  achievable  within  the  time,  resource  and  risk 
constraints  of  the  project; 

e.  schedules  for  the  development  and  delivery  of  products  and  processes  are 
mutually  supportive;  and 

f.  the  total  impact  to  defence  of  changes  to  the  technical  requirements  with 
respect  to  cost,  schedule,  performance,  and  risk  are  defined  and  reported  and  their 
effects  determined.*® 

Verification 

The  verification  activity  (figure  1 1)  progressively  checks  that  the  product  and 
process  designs  satisfy  their  requirements.  Since  in  the  Army’s  case  the  major  product 
being  designed  will  usually  be  a  systems  specification  rather  than  a  hardware  system,  the 
verification  process  ensures  that  the  specifications  are  actually  required. 

Plans 

In  order  to  implement  the  Systems  Engineering  process  a  Systems  Engineering 
Management  Plan  (SEMP)  is  required.  A  SEMP  represents  the  tailoring  of  a  Systems 
Engineering  Standard,  such  as  El  A  Standard  IS-632  to  meet  that  organisation’s  needs. 
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The  SEMP  is  updated  regularly  and  describes  the  Systems  Engineering  process  and  the 
organisation’s  plan  to  execute  that  process.  It  provides  a  focus  for  the  integration  of 
engineering  specialties.  The  SEMP  becomes  a  sub  plan  of  a  Project  Management  and 
Acquisition  Plan  (PMAP).  This  is  the  central  document  that  outlines  how  a  project  is  to 
be  managed.  The  PMAP  details  how  the  project  management,  Systems  Engineering  and 
logistics  requirements  for  a  project  are  to  be  completed. 

Logistic  Support 

The  DI(G)ADMIN  05-1  mandates  that  logistic  support  issues  be  considered  as 
part  of  the  planning  and  preparation  for  a  capability  seeking  project  approval.  The 
Capital  Equipment  Procurement  Manual  (CEPMAN  1)  also  requires  that  logistics  issues 
be  considered  as  part  of  the  project  planning  process.  A  systems  approach  to  the 
development  of  a  capability  must  consider  all  of  the  logistics  issues  necessary  to  assure 
that  an  equipment  system  is  supported  effectively  and  economically  throughout  its 
programmed  life.  To  achieve  this,  the  Australian  Defence  Force’s  Logistic  Support 
Manual  (LOGMAN)  provides  policy  and  procedural  guidance  to  assist  in  adopting  a 
unified  approach  to  logistic  support. 

Logistic  support  aims  to: 

a.  achieve  preparedness  objectives  at  minimum  life  cycle  cost; 

b.  provide  an  integrated  and  systems  approach  to  logistic  support  aspects  using 
the  management  tools  of  ILS  (ILS),  Logistic  Support  Analysis  (LSA),  Reliability 
and  Maintainability  (RAM)  and  Life  Cycle  Costing  (LCC)  throughout  the  life 
cycle;  and 
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c.  create,  store,  retrieve,  distribute  and  use,  data  and  information  in  digital  format 
to  aid  management  decision  making.*’ 

Integrated  Logistics  Support 

The  ILS  is  the  basis  for  the  development  of  supportability  for  an  equipment 
system  for  its  entire  service  life  whilst  minimizing  life  cycle  costs.  The  ILS  is  a  total 
support  concept.  The  elements  of  ILS  include  all  of  the  considerations  necessary  to 
ensure  adequate  and  economic  support  is  provided  for  an  equipment  system.  The  core 
elements  of  ILS  are: 

a.  maintenance  planning; 

b.  engineering  support; 

c.  supply  support; 

d.  support  and  test  equipment; 

e.  technical  data; 

f.  manpower  and  personnel; 

g.  training  and  training  support; 

h.  facilities; 

i.  packaging,  handling,  storage  and  transportation;  and 

j.  computing  support. 

These  elements  are  to  be  considered  to  varying  degrees  and  additional  elements 
added  depending  on  the  equipment  systems  under  consideration  for  each  capability. 

It  is  Defence  policy  that:  “The  principles  of  ILS  shall  be  applied  to  all  projects 
including  software,  collaborative  and  non-developmental  projects.  The  ILS  is  to  be 
applied  to  non-developmental  projects  dxuing  the  concept  and  acquisition  phases  in 
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sufficient  depth  to  ensure  that  selection  is  based  on  total  life-cycle  costs  and  that  support 
implications  are  clearly  linked  to  the  decision  taken.”*^ 

The  objectives  of  ILS  are  to  influence  the  design  of  a  capability  to  ensure  that  it 
has  a  desired  level  of  availability  whilst  minimizing  support  requirements  and  life-cycle 
costs.  It  also  aims  to  ensure  that  all  of  the  appropriate  ILS  elements  are  planned,  assessed 
and  implemented  in  parallel  with  the  development,  acquisition,  operation  and  disposal  of 
the  system.  The  application  of  ILS  should  prepare  users  and  support  elements  to  operate 
and  support  new  equipment.  It  also  should  provide  procedures  to  acquire,  integrate  and 
dispose  of  the  system.  The  ILS  aims  to  ensure  that  supportability  and  life-cycle  costing 
issues  are  given  adequate  consideration  in  the  requirements  determination  and  acquisition 
processes.*^ 

During  the  concept  phase,  ILS  objectives  are  concerned  with  alternative  solutions 
to  satisfy  the  operational  requirements.  The  aim  is  to  design  for  support.  During  the 
acquisition  phase  ILS  is  predominantly  directed  towards  the  development  of  maintenance 
schedules,  spares  assessing  and  procurement,  training  development,  supportability  and 
test  equipment  and  documentation. 

Reliability,  Availability  and  Maintainability 
Reliability,  Availability,  and  Maintainability  (RAM)  requirements  must  be 
specified  early  in  the  concept  phase.  They  provide  the  engineering  basis  for  all 
subsequent  logistics  activities.  Without  their  inclusion  in  the  initial  requirements 
definition,  there  is  no  basis  provided  for  subsequent  logistics  planning.  During  the 
acquisition  phase  reliability  and  maintainability  predictions  and  allocations  are  conducted 
to  ensure  that  the  design  meets  the  supportability  requirements.  Reliability  and 
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maintainability  demonstrations  may  be  conducted  towards  the  end  of  the  physical  design 
process  as  appropriate  for  the  capability  being  acquired. 


Life  Cycle  Costing 

One  of  the  first  tasks  to  be  completed  in  the  concept  phase  is  to  produce  a  broad 
estimate  of  the  financial  cost  of  the  required  capability.  This  estimate  is  updated  as  the 
capability  takes  on  a  greater  level  of  definition.  In  the  concept  phase  this  estimate  is 
refined  into  Pink  Book  figures  and  is  used  to  support  the  detailed  design,  development 
and  production  process.  It  is  important  that  these  figures  are  accurate  as  they  define  the 
limits  for  spending  on  a  capability  in  the  acquisition  phase. 

In  the  acquisition  phase  the  Pink  Book  estimates  are  again  refined.  Life  cycle 
costs,  rather  than  just  acquisition  costs,  should  be  used  in  the  tender  evaluation  process  as 
the  basis  for  comparison  between  tenderers. 

Studies  conducted  by  the  US  DOD*"^  of  Defence  Projects  over  the  past  twenty 
years  showed  that  if  a  change  to  increase  supportability  were  made  during  the  design 
process  and  cost  $1.00,  that  same  change  made  during  production  would  cost  $100,000. 

If  the  change  were  not  made  until  after  introduction,  the  cost  would  escalate  to 

$1,000,000. 

Whilst  exact  figures  vary  from  different  sources,  it  is  generally  held  that  by  the 
end  of  the  concept  phase,  70  percent  of  the  decisions  affecting  life  cycle  costs  have  been 
made.  Approximately  85  percent  of  the  decisions  have  been  made  once  the  system  is 
fully  defined  in  the  acquisition  phase  and  by  the  time  a  contract  for  a  capability  is  signed, 
90  percent  of  through-life  costs  have  been  established  (figure  17).*^ 


The  Australian  Logistic  Support  Manual  is  less  conservative  and  states  that  a 
higher  percentage  of  decisions  occur  even  earlier  for  developmental  projects.  It  states 
that,  “for  a  typical  full  developmental  program,  90  percent  of  the  decisions  affecting  Life 
Cycle  Costs  (LCC)  would  have  been  made  at  the  end  of  the  concept  phase  and  only  10 
percent  of  the  cost  reduction  opportunities  would  be  available  after  this  phase,”*^  This 
highlights  the  need  to  get  requirements  determination  and  system  definition  right  as  early 
as  possible  from  both  the  logistics  and  the  technical  side. 


Figure  17.  Life  Cycle  Cost  Definition 


If  sufficient  effort  is  not  given  to  adequately  developing  the  capability 
requirements  in  the  concept  phase  then  defence  will  ultimately  procure  a  capability  with  a 
higher  than  necessary  life-cycle  cost.  The  basis  for  accurate  cost  estimation  will  also  be 
inadequate.  Basing  cost  estimates  on  an  inadequately  defined  capability  requirement 
significantly  increases  the  risk  that  project  cost  overruns  will  occur  in  the  acquisition  and 
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in-service  phases.  Cost  overruns  reduce  defence’s  ability  to  manage  its  limited  budget 
and  achieve  the  introduction  into  service  of  the  full  range  of  required  capabilities. 

Major  ILS  Products 

In  the  concept  phase  a  logistics  support  concept  must  be  developed  as  early  as 
possible  in  the  process  so  that  supportability  is  considered  in  the  system  design  when 
changes  are  easy  and  inexpensive  to  implement.  The  first  product  of  the  logistics  support 
concept  is  the  maintenance  concept.  It  is  from  this  product  that  all  other  ILS  elements 
take  their  lead. 

Consideration  of  ILS  elements,  LSA  strategy  and  ILS  management  should  be 
included  in  the  military  options  papers,  options  papers  and  issues  papers.  It  is  important 
that  these  identify  support  concepts,  objectives  and  areas  of  risk  early  in  the  concept 
phase.  Of  particular  importance  is  the  need  to  make  an  early  estimate  of  the  life-cycle 
costs  of  the  options  to  be  considered.  If  the  cost  of  logistics  support  is  not  considered 
until  the  acquisition  phase,  it  could  have  a  detrimental  effect  on  the  operational  aspects  of 
the  capability  to  be  procured.*’ 

In  the  acquisition  phase  the  first  iteration  of  an  ILS  Plan  (ILSP)  must  be 
developed  as  early  as  possible.  The  ILSP  is  the  business  plan  for  logistics.  The  Project 
Management  and  Acquisition  Plan  (PMAP)  is  the  business  plan  for  the  project  which 
controls  the  management  of  ILS,  Systems  Engineering  and  project  management, 
activities  for  the  project.  The  ILSP  is  a  subset  of  the  PMAP. 

A  logistics  Statement  of  Requirement  is  also  written  at  this  stage.  This  is 
included  in  tender  documentation  for  a  required  capability  and  is  converted  into  a 
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logistics  Statement  of  Work  on  the  award  of  a  contract.  A  suite  of  other  supporting 
logistics  products  is  developed  during  this  phase.’* 

Logistic  Support  Analysis 

The  ILS  is  underpinned  by  LSA.  The  LSA  is  detailed  in  MIL-STD-1388-1 A  and 
LOGMAN.  It  is  an  analytical  tool  that  provides  a  methodology  to  integrate  ILS  and 
provides  a  logical  progression  of  events  for  ILS  application.  It  is  a  structured  approach  to 
evaluating  the  logistic  support  characteristics  of  a  design  and  for  assessing  in-service 
support  requirements.  Conducting  LSA  ensures  that  each  of  the  elements  of  ILS  are 
considered  in  the  system  design. 

LSA  applies  to  all  phase  of  a  capability’s  life  cycle.  It  is  an  iterative  process  that 
conducts  studies,  analyses  and  trade-offs,  and  tests  and  trials  with  the  aims  of 
successfully  refining  an  equipment  system’s  design  and  optimizing  its  support 
requirements. 

LSA  must  be  tailored  to  suit  the  individual  characteristics  of  each  capability 
development  project.  No  one  model  for  the  application  of  LSA  will  apply  to  all  projects. 
However,  this  study  will  provide  a  generic  model  for  the  application  of  LSA  in  the 
concept  and  acquisition  phases.  The  purpose  of  this  is  to  indicate  the  timing  and 
integration  of  logistics  issues  into  the  development  and  acquisition  process  rather  than  to 
mandate  the  standardized  use  of  specijSc  LSA  Tasks. 

Major  LSA  Tasks 

The  conduct  of  LSA  breaks  down  into  a  series  of  tasks.  The  LSA  tasks  do  not 
represent  additional  requirements  that  increase  project  schedules,  management  or 
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tendering  costs.  They  are  the  most  effective  way  of  meeting  the  logistics  support 
requirements  already  prescribed  in  Defence  policies. 

The  LSA  tasks  for  a  project  in  LOGMAN  and  MIL-STD-1388-1 A  are: 

a.  Task  Section  100— LSA  Planning  and  Control; 

b.  Task  Section  200—Mission  Support  Systems  and  Definition; 

c.  Task  Section  300--Preparation  and  Evaluation; 

d.  Task  Section  400— Determination  of  Logistic  Support  Requirements;  and 

e.  Task  Section  500— Supportability  Assessment. 

A  detailed  list  of  LSA  tasks  and  sub-tasks  is  contained  in  appendix  B.  Not  all  tasks  need 
to  be  applied  to  all  projects.  The  use  of  appropriate  tasks  should  be  tailored  to  each 
project. 

The  objective  of  LSA  in  the  concept  phase  is  to  allow  logistics  issues  to  influence 
the  way  a  system  is  to  be  supported.  The  LSA  strategy  and  supportability  related  tasks 
such  Front  End  Logistic  Support  Analysis  are  conducted  in  this  phase.  Although, 
historically  the  Lise  Study  has  been  written  in  the  acquisition  phase,  it  should  be  written 
in  the  concept  phase.  This  task  will  go  through  a  number  of  iterations  and  will  take  on  an 
increasing  level  of  definition  throughout  the  phase.  In  the  initial  stages,  the  results  of 
these  LSA  tasks  will  have  little  definition.  However,  it  is  important  that  they  each  be 
considered  as  early  as  possible  to  ensure  that  logistics  issues  are  adequately  addressed  in 
the  system  design. 

In  the  acquisition  phase  the  LSA  Plan  is  written  and  the  LSA  Tasks  relevant  to  the 
project  are  progressed.  Completion  of  the  LSA  tasks  results  in  a  suite  of  integrated 


63 


logistics  studies  and  ILS  data.  These  ILS  data  are  in  the  form  of  a  relational  database 
known  as  the  LSA  Record  or  LSAR. 

The  completion  of  LSA  tasks  occurs  through  a  series  of  iterations  throughout  the 
materiel  cycle.  For  example,  the  production  of  an  LSA  strategy  should  be  started  in  the 
early  stages  of  the  concept  phase.  It  must  be  continually  refined  and  will  not  be 
completed  until  the  system  definition  stage  in  the  acquisition  phase.  A  recommended 
implementation  for  the  primary  LSA  sub-tasks  in  the  concept,  acquisition  and  in-service 
phases  is  shown  in  figure  1 8.*’  This  is  based  on  guidance  from  LOGMAN. 

Project  Management 

Another  discipline  critical  to  the  systematic  development  of  a  capability  in  the 
concept  and  acquisition  phases  is  Project  Management.  It  is  necessary  to  examine  the 
relationship  of  Project  Management  to  Systems  Engineering  and  ILS  in  order  to 
understand  its  role  in  a  systems  development  methodology. 

Project  Management,  Systems  Engineering  and  ILS  are  disciplines  that  when 
applied  to  the  development  of  a  capability,  should  assist  the  capability  to  be  brought  into 
service  on  time,  within  budget,  and  with  an  agreed  level  of  quality.  Their  relationship  is 
shown  in  figure  19. 

The  balance  between  these  three  disciplines  varies  throughout  the  concept  and 
acquisition  phases.  For  example,  the  application  of  formal  project  management 
techniques  does  not  normally  occur  until  a  project  team  within  the  Defence  Acquisition 
Orgamsation  is  formed  just  prior  to  the  commencement  of  the  acquisition  phase.  Systems 
engineering  and  ILS  are  also  applied  at  increasing  levels  of  definition  throughout  the 
concept  and  acquisition  phases,  with  the  initial  application  being  requirements  definition 
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Figure  18.  LSA  Tasks  and  sub-tasks  by  product  and  phase. 


Legend:  EAS  -  Equipment  Acquisition  Strategy 

PDS  -  Project  Definition  Study 
FSD  -  Full  Scale  Development 
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Figure  19.  Project  Management,  Systems  Engineering  and  Integrated  Logistics  Support 

Relationship 

and  logistics  use  studies.  The  integration  of  Systems  Engineering  and  ILS  produces  a 
complete  methodology  for  the  systematic  development  of  a  capability. 

There  are  two  different  ways  of  viewing  the  relationship  between  ILS  and 
Systems  Engineering.  The  first  sees  ILS  as  a  function  included  within  Systems 
Engineering  which  only  becomes  a  separate  function  after  the  system  design  becomes 
mature.  The  second  views  ILS  and  Systems  Engineering  as  separate  functions  that  exist 
within  a  project  and  exchange  data  and  guidance.  This  approach  represents  the  current 
way  most  projects  are  organized  and  represents  Army’s  current  position. 

This  integrated  application  of  Systems  Engineering  and  ILS  produces  a  systems 
development  methodology  that  could  be  adopted  by  the  Australian  Army  to  ensure  that  a 
systems  approach  is  applied  to  the  concept  and  acquisition  phases  of  the  materiel  cycle. 
The  application  of  project  management  techniques  to  this  systems  approach  should  result 
in  the  capability  being  brought  into  service  within  budget,  having  considered  all  of  the 
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aspects  affecting  the  system.  It  should  have  an  optimal  life  cycle  performance,  satisfy 
customer  needs  and  meet  the  constraints  on  the  system. 

The  relationship  between  the  attributes  of  Systems  Engineering,  ILS  and  project 
management  are  shown  in  figure  20. 

Figure  20  shows  important  overlaps  between  the  three  key  disciplines  of  Systems 
Engineering,  ILS  and  project  management.  Those  attributes  shown  as  being  unique  to 
project  management  are  the  more  commercial  aspects  of  the  task  conducted  within  the 
Defence  Acquisition  Organization.  Whilst  the  three  disciplines  are  clearly  related. 
Systems  Engineering  and  ILS  are  primarily  concerned  with  managing  the  capability  and 
project  management  is  concerned  with  managing  the  project.  Therefore  any 
methodology  that  aims  to  ensure  that  a  systems  approach  is  applied  to  the  concept  and 
acquisition  phases  of  the  materiel  cycle  should  integrate  Systems  Engineering  and  the 
elements  of  ILS.  This  methodology  should  then  be  implemented  using  project 
management  techniques. 

In  further  defining  the  relationship  between  Systems  Engineering  and  the 
elements  of  ILS  it  should  be  remembered  that  LSA  is  the  structured  methodology  that 
integrates  and  applies  the  various  elements  of  ILS  across  the  materiel  cycle.  Its 
relationship  to  Systems  Engineering  is  outlined  in  MIL-STD-1388-1 A  and  LOGMAN. 
These  references  state  its  application  as  being,  “part  of  the  Systems  Engineering  and 
design  process,  to  assist  in  complying  with  the  supportability  and  other  Integrated 
Logistics  Support  (ILS)  objectives  through  the  use  of  an  iterative  process  of  definition, 
synthesis,  trade-off,  test  and  evaluation. This  means  that  to  carry  out  ILS  you  must 
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complete  LSA  tasks.  Therefore,  in  order  to  integrate  Systems  Engineering  and  ILS  you 
must  integrate  Systems  Engineering  and  LSA  tasks. 
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Figure  20.  Relationship  between  the  attributes  of  the  Systems  Engineering,  Integrated 
Logistics  Support  and  Project  Management 


It  is  now  possible  to  examine  how  Systems  Engineering  and  LSA  can  be 
integrated  to  produce  a  systems  development  methodology  for  the  Australian  Army 
which  can  be  applied  in  the  concept  and  acquisition  phases  of  the  materiel  cycle. 
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Systems  Development  Methodology 

Figiire  10  outlined  the  key  capability  development  products  in  the  concept  and 
acquisition  phase.  Figure  1 1  outlined  the  Systems  Engineering  process  and  figure  18 
outlined  which  LSA  tasks  are  to  be  conducted  at  various  stages  in  the  capability 
development  process.  The  integration  of  these  areas  produces  a  systems  development 
methodology  for  the  Australian  Army  that  can  be  applied  in  the  concept  and  acquisition 
phases  of  the  materiel  cycle.  This  methodology  will  be  presented  in  terms  of  the 
development  of  key  capability  development  documentation. 

The  first  key  document  to  be  produced  is  the  Military  Options  Paper.  The  Land 
Development  Branch  within  Capability  Development  Division  has  prime  responsibility 
for  this.  They  receive  input  from  the  Combined  Arms  Training  and  Development  Centre. 
The  Military  Options  Paper  should  be  developed  in  accordance  with  figure  21 . 

The  second  key  document  is  the  Options  Paper.  The  Capability  Development 
Division  has  prime  responsibility  for  this  and  is  assisted  by  the  Capability  Programming 
and  Resource  Planning  Division.  It  should  be  developed  in  accordance  with  figure  22. 

The  third  key  document  is  the  Issues  Paper.  The  Capability  Development 
Division  also  has  prime  responsibility  for  this  and  is  assisted  by  the  Capability 
Programming  and  Resource  Planning  Division.  It  should  be  developed  in  accordance 
with  figure  23. 

The  process  described  as  “System  Design”  occurs  in  the  acquisition  phase.  It  is 
the  prime  responsibility  of  the  Defence  Acquisition  Organisation.  It  should  be  developed 
in  accordance  with  figure  24. 
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Figure  21 .  Systems  Development  Methodology-Military  Options  Paper 
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Figure  22.  Systems  Development  Methodology— Options  Paper 
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Support  Tradeoff  Analysis 
(303) 


Figure  23.  Systems  Development  Methodology-Issues  Paper 
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Figure  24.  Systems  Development  Methodology-System  Design 


Figure  25  outlines  the  prime  responsibility  for  applying  the  systems  development 
methodology  in  the  various  stages  of  the  concept  and  acquisition  phases.  It  shows  that 
primary  responsibility  lies  with  the  Combined  Arms  Training  and  Development  Centre 
(CATDC),  the  Land  Development  Branch  within  Capability  Development  Division  (CD 
Div)  and  the  Defence  Acquisition  Organisation  (DAO). 


Acquisition 
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Figure  25.  Responsibility  for  applying  the  Systems  Development  Methodology  in  the 

Concept  and  Acquisition  Phases 


Figures  21  to  25  outline  a  systems  development  methodology  that  the  Australian 
Army  could  adopt  to  ensure  that  a  systems  approach  is  applied  to  the  concept  and 
acquisition  phases  of  the  materiel  cycle.  While  the  Organisational  structures  and 
capability  development  processes  within  the  Australian  Defence  Force  are  likely  to 
change  in  future,  the  utility  of  this  methodology  will  remain  extant.  It  provides  a  “work 
in  progress”  that  can  be  adapted  to  the  given  Organisations  and  processes  in  place  at  the 
time. 
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While  use  of  this  methodology  would  be  of  direct  benefit  to  the  Army,  its 
implementation  would  pose  a  number  of  challenges.  It  would  impose  a  training  liability 
on  the  Defence  Force.  At  present  neither  the  CATDC,  the  Land  Development  Branch 
within  the  CD  Div  or  CPRP  have  the  skills,  expertise  or  experience  to  apply  this 
methodology.  The  ability  of  the  DAO  to  do  so  is  limited.  Additional  manpower  and 
resources  may  be  required  within  CATDC,  CD  Div,  CPRP  and  DAO.  The  capability 
development  and  acquisition  process  is  defence  wide,  therefore,  implementation  of  the 
methodology  would  need  to  be  conducted  within  the  context  of  the  defence  capability 
development  processes.  In  particular,  agreement  would  have  to  be  sought  from  the 
members  of  the  Capability  Forum  and  the  Defence  Capability  Committee  as  they 
consider  and  approve  key  capability  development  documentation  that  result  from  the 
application  of  this  methodology. 

WTiile  there  are  challenges  for  implementation  of  this  methodology  at  the  present 
time,  its  application  would  ensure  that  a  systems  approach  was  applied  to  the  concept  and 
acquisition  phases  of  the  materiel  cycle.  This  would  provide  long  term  and  lasting 
benefits  that  would  justify  the  investment  required  for  its  implementation. 

'Robert  Halligan ,  Systems  Engineering  for  Defence  and  Aerospace:  From 
Concept  Exploration  to  Introduction  into  Service-ATEA  Course  Notes,  (Melbourne: 
Technology  Australasia,  September  1995),  Slide  No.  19. 

2 

us  DoD,  DoD  5000. 2-R  Mandatory  Procedures  for  Major  Defence  Acquisition 
Programs  (MDAPs)  and  Major  Automated  Information  System  (MAIS)  Acquisition 
Programs,  (Washington  DC:  US  DoD,  15  March  1996,  Part  4  Section  4-3),  1. 

^Electronic  Industries  Association,  ElA  Standard  IS-63 2-Systems  Engineering, 
(Washington  DC:  Electronic  Industries  Association  Engineering  Department,  December 
1994),  Figure  3,  8. 

'‘ibid.,  9. 
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^Ibid.,  9. 


Defence  Systems  Management  College,  Systems  Engineering  Management 
Guide,  1983  edition,  (Washington  DC:.  US  Government  Printing  Office,)  6-1. 

Technology  Australasia,  Standard  No.  001  Systems  Engineering,  Issue  3, 
(Melbourne:  Technology  Australasia,  20  September  1996),  13,  Figure  2. 

*Ibid.,  13,  Figure  10. 

^Electronic  Industries  Association,  10. 

*®Ibid.,  11. 

"Department  of  Defence  Logistics  Division,  Logistic  Support  Manual  LOGMAN, 
(Canberra:  Commonwealth  of  Australia,  October  1996),  Amendment  1,  Part  1  Section  1 
1-1-3. 


"ibid..  Part  2  Section  1,  Chapter  1, 2-1 -1-3. 

"ibid..  Part  2  Section  1  Chapter  1, 2-2-1-3, 2-1-1-4. 

"Keith  Gascoyne  and  Peter  King,  ILS  Awareness  Course— Student  Notes, 
(Canberra:  Computer  Power  and  Total  Logistics  Management,  28  March  1996),  2. 

"Keith  Gascoyne  &  Peter  King,  Lesson  No  BA_19,  Figure,  3. 

"Department  of  Defence  Logistics  Division,  Part  2  Section  1  Chapter  1, 2-1-2-2. 

17 

Department  of  Defence  Logistics  Division,  Part  2  Section  1  Chapter  1, 


"Keith  Gascoyne  and  Peter  King,  6. 

"Department  of  Defence  Logistics  Division,  Part  2  Section  4  Chapter  1, 

Aimex  A,  2-4-1 A-1. 

^®Ibid.,  Part  2  Section  1  Chapter  1, 2-1-1-5. 

21 

TDA  Systems  Engineering  and  BALL  Aerospace  and  Technologies  Corp, 
Defence  Acquisition  Organization-Systems  Engineering  Training,  (Canberra:  TDA 
Systems  Engineering,  Course  Notes,  29  September  to  1  October  1997),  1-8. 

22 

Department  of  Defence  Logistics  Division,  Part  2  Section  4  Chapter  1, 2-4- 1-2. 
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CHAPTER  5 


CONCLUSION,  RECOMMENDATIONS,  AND  SUGGESTIONS 
FOR  FURTHER  RESEARCH 

Conclusion 

A  systems  approach  to  capability  development  must  consider  all  of  the 
requirements  influencing  the  capability  being  introduced  into  service.  The  methodology 
that  the  Australian  Army  should  adopt  to  ensure  that  a  systems  approach  is  applied  to  the 
concept  and  acquisition  phases  of  the  materiel  cycle  is  an  integration  of  Systems 
Engineering,  Integrated  Logistics  Support  (ILS),  and  Logistic  Support  Analysis  (LSA). 

Systems  Engineering  is  an  interdisciplinary  approach  that  aims  to  deliver  systems 
providing  an  optimmn,  balanced,  coherent  solution  to  satisfy  customer  needs.  It  is  an 
orderly,  structured,  disciplined  and  systematic  process.  It  attacks  large  problems  by 
breaking  them  down  into  smaller  ones,  and  ensures  that  the  solutions  of  the  smaller 
problems  are  integrated  into  the  solution  of  the  larger  problem.  An  important  aspect  of 
this  process  is  traceability  and  accountability.  The  process  examines  all  of  the  elements 
that  interface  with  a  system.  In  this  way  it  seeks  to  optimize  the  quality  of  a  system 
throughout  its  entire  life  cycle. 

As  applied  to  an  Army  equipment  system.  Systems  Engineering  includes  but  is 
not  limited  to,  capability  development,  project  management,  engineering,  and  logistics.  It 
is  a  management  or  problem  solving  approach,  rather  than  a  technical  approach,  even 
though  there  are  specific  standards  that  outline  its  implementation.  The  goal  of  Systems 
Engineering  is  to  completely  and  correctly  identify  and  validate  the  requirements  that 
apply  to  a  capability  and  to  transform  them  into  a  description  of  system  elements  that  best 
satisfy  these  requirements.  It  aims  to  achieve  these  goals  at  a  cost  equal  to  or  better  than 
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budget  and  in  a  total  time  equal  to  or  better  than  schedule.  The  standard  that  currently 
has  greatest  utility  for  the  Australian  Defence  Force  to  use  as  guidance  is  EIA  Standard 
IS-632.  This  standard  outlines  the  key  activities  of  Systems  Engineering  as; 

a.  Requirements  Analysis; 

b.  Functional  Analysis/ Allocation; 

c.  Synthesis;  and 

d.  Systems  Analysis  and  Control. 

The  ILS  is  another  whole  of  life  management  discipline  that  aims  to  deliver  a 
complete  system  that  meets  user  needs.  It  aims  to  integrate  all  support  and  service 
considerations  for  a  materiel  system  and  provide  a  seamless  transition  of  support 
activities  between  each  phase  of  the  materiel  cycle. 

Within  the  concept  and  acquisition  phases,  ILS  aims  to  ensure  that: 

a.  consideration  of  support  factors  is  integral  to  the  development  of  capability 

options, 

b.  support  considerations  influence  design  requirements  and  selection, 

c.  support  requirements  are  used  in  optimizing  a  materiel  system’s  performance, 

d.  required  support  elements  are  acquired  or  implemented.* 

LSA  provides  a  single  anal5dical  approach  to  enable  support  considerations  to 
influence  the  design  requirements  and  design  selection  for  a  materiel  system.  It  is  the 
tool  that  integrates  ILS  and  the  engineering  functions.  It  is  made  up  of  a  series  of  tasks 
that  when  performed  ensures  that  each  element  of  ILS  is  considered  along  with  the 
system  design.  To  carry  out  ILS  you  must  complete  LSA  tasks.  Therefore,  in  order  to 
integrate  Systems  Engineering  and  ILS  you  must  integrate  Systems  Engineering  and  LSA 
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tasks.  The  systems  development  methodology  integrates  LSA  tasks  into  each  of  the  key 
activities  of  the  Systems  Engineering  process.  The  methodology  is  tailored  to  each  of  the 
key  outputs  from  the  capability  development  process. 

The  key  outputs  from  the  capability  development  process  are  Military  Options 
Papers,  Options  Papers  and  Issues  Papers  in  the  concept  phase,  and  the  system  design 
activities  in  the  acquisition  phase  (figure  25).  The  four  key  organisations  for  the  Army  in 
the  concept  and  acquisition  phases  of  the  materiel  cycle  are  the  Combined  Arms  Training 
and  Development  Centre  (CATDC),  the  Capability  Programming  and  Resource  Planning 
Division  (CPRP),  Land  Development  Branch  within  the  Capability  Development 
Division  (CD  Div)  and  the  Defence  Acquisition  Organization  (DAO). 

CD  Div,  assisted  by  the  CATDC,  is  responsible  for  producing  the  Military 
Options  papers.  CD  Div,  assisted  by  CPRP  is  responsible  for  producing  Options  and 
Issues  papers.  DAO  is  responsible  for  completing  the  System  Design  activities. 

Figures  21  to  25  outline  the  responsibility  of  each  of  these  organisations  for 
applying  the  systems  development  methodology.  While  the  organisational  structures  and 
capability  development  processes  within  the  Australian  Defense  Force  are  likely  to 
change  in  future,  the  utility  of  this  methodology  will  remain  extant.  It  provides  a  “work 
in  progress”  that  can  be  adapted  to  the  given  organisations  and  processes  in  place  at  the 
time. 

Recommendations 

It  is  recommended  that: 

a.  The  Land  Development  Branch  within  the  Capability  Development  Division 

and  the  Combined  Arms  Training  and  Development  Centre  apply  an  integration 
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of  Systems  Engineering,  ILS,  and  LSA  as  outlined  in  figure  21,  to  produce 
Military  Options  Papers. 

b.  The  Land  Development  Branch  within  the  Capability  Development  Division 
and  the  Capability  Programming  and  Resource  Planning  Division  apply  an 
integration  of  Systems  Engineering,  ILS,  and  LSA  as  outlined  in  figure  22,  to 
produce  Options  Papers. 

c.  The  Land  Development  Branch  within  the  Capability  Development  Division 
and  the  Capability  Programming  and  Resource  Planning  Division  apply  an 
integration  of  Systems  Engineering,  ILS,  and  LSA  as  outlined  in  figure  23,  to 
produce  Issues  Papers. 

d.  The  Defence  Acquisition  Organisation  apply  an  integration  of  Systems 
Engineering,  ILS,  and  LSA  as  outlined  in  figure  24,  to  complete  System  Design 
activities. 

e.  The  application  of  the  systems  development  methodology  to  Military  Options 
Papers,  Options  Papers,  Issues  Papers  and  Systems  Design  activities  be  developed 
progressively  as  outlined  in  figure  25. 

Areas  for  Further  Research 

There  are  three  areas  where  further  research  might  add  a  significant  knowledge  to 
this  field.  The  constraints  of  time  and  the  limited  scope  of  this  study  precluded  their 
investigation  in  this  paper. 

How  do  the  findings  of  the  Capability  Management  Improvement  Team 
(CMIT)  affect  the  implementation  of  the  systems  development  methodology? 
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The  CMIT  aimed  to  overcome  the  current  segmentation  of  capability  management 
that  currently  exists  within  defense,  and  achieve  a  more  seamless  life  cycle 
management  of  capability.  The  outcomes  of  the  team’s  study  are  likely  to  have  a 
major  impact  on  the  nature  and  implementation  of  the  systems  development 
methodology.  Further  research  should  examine  how  implementation  of  this 
methodology  within  the  Army  would  affect  defense  wide  capability  development 
processes. 

b.  What  are  the  training  requirements  for  implementation  of  the  systems 
development  methodology?  A  comprehensive  training  program  is  likely  to  be 
required  for  the  CATDC,  CD  Div,  CPRP  and  DAO.  Without  sufficient  skills, 
expertise  and  experience  within  these  organisations,  the  systems  development 
methodology  will  not  be  able  to  be  sufficiently  implemented  or  maintained. 

c.  What  are  the  resource  and  manpower  requirements  for  the  implementation  of 
the  systems  development  methodology?  Additional  resources  and  manpower  are 
likely  to  be  required  for  the  CATDC,  CD  Div,  CPRP  and  DAO.  This  study 
should  examine  the  appropriate  balance  between  uniformed  personnel,  public 
servants  and  defense  contractors.  It  should  also  examine  the  requirement  for 
integrated  support  systems,  such  as  Systems  Engineering  software  tools  and 
decision  support  databases. 


*  Australian  Department  of  Defence,  Defence  Instruction  (General)  LOG  03-6  - 
Defence  Policy  on  Integrated  Logistics  Support,  (Canberra:  Commonwealth  of  Australia, 
26  May  1997),  1. 
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APPENDIX  A 


fflSTORICAL  PROJECT  DATA-AUSTRALIAN  DEFENCE  PROJECTS 

Shown  below  are  the  statistics  from  the  Australian  Department  of  Defence 
showing  cost  overruns  and  schedule  slippages  for  sixteen  Defence  projects.’ 


Schedule  Slippages 


Project 

Percentage  schedule 
overrun 

TADS 

71 

Jindalee  -  Stage  A 

35 

Jindalee  -  Stage  B 

22 

C-130H  Simulator 

31 

F1 1 1 A  Attrition  Aircraft 

82 

Basic  Trainer  (Phase2) 

22 

P3C  Orion 

0 

F/A-18  Tactical  Fighter 

0 

Rapier  Air  Defence 

0 

Hiport/Medport 

80 

Medium  Trucks 

0 

Small  Arms 

0 

Hamel  light  gun 

0 

HMAS  Success 

70 

Minehunter  Catamarans 

57 

US  built  FFGs:  FFG01 

6 

US  built  FFGs:  FFG02 

5 

US  built  FFGs;  FFG03 

2 

US  built  FFGs:  FFG04 

6 

Australian  Frigates 

0 
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Percentage  schedule  overrun 


Historical  Schedule  Slippage  -  Australian  Defence  Projects 
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Project 

Real  Cost  Overrun 

TADS 

-5 

Jindaiee  -  Stages  A&B 

25.3 

C-130H  Simulator 

59.6 

F1 1 1 A  Attrition  Aircraft 

-9.7 

Basic  Trainer  (Phases  1  &  2) 

106 

P3C  Orion 

16.6 

F/A-1 8  Tactical  Fighter 

-7.3 

Rapier  Air  Defence  (Phases  1  &  2) 

1.9 

Hiport/Medport 

8 

Medium  Trucks 

-2.4 

Small  Arms  (Phases  1  &  2) 

0 

Hamel  light  gun  (Phases  1 ,2  &  3) 

-8.1 

HMAS  Success 

98.6 

Minehunter  Catamarans  (Phases  1  &  2) 

6.6 

US  built  FFGs 

^  177.5 

Australian  Frigates 

0 
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Historical  Cost  Overruns  Australian  Defence  Projects 


Projects 


a  Real  Cost  Overrun  g 


'Department  of  Defence,  Minutes  of  Evidence,  Volume  2,  Chapters  2-17  &  pages 
2825-2828  cited  in  R.  Halligan,  ‘Systems  Engineering  for  Defence  and  Aerospace:  from 
concept  exploration  to  introduction  into  service-ATEA  Notes’,  Technology  Australasia, 
Melbourne,  1995,  Additional  Notes. 


85 


APPENDIX  B 


LOGISTIC  SUPPORT  ANALYSIS  TASKS 


Shown  below  is  a  list  of  the  Logistic  Support  Analysis  (LSA)  tasks  and  sub-tasks. 
LSA  should  be  tailored  to  each  capability  by  conducting  those  tasks  and  sub-tasks 
relevant  to  the  project. 


Task/  Subtasks  Title 

101  Development  of  an  early  Logistic  Support  Analysis  Strategy 

1 0 1 .2. 1  Supportability  Objectives 

101.2.2  Cost  Estimate 

101.2.3  Updates 


102  Logistic  Support  Analysis  Plan 

102.2.1  LSA  Plan 

102.2.2  Updates 

103  Program  &  Design  Reviews 

1 03 .2. 1  Establish  Review  Procedures 

103.2.2  Design  Reviews 

1 03 .2.3  Program  Reviews 

103.2.4  LSA  Review 

103.2.5  LSA  Guidance  Conferences 


201  Use  Study 

20 1 .2. 1  Supportability  Factors 

201.2.2  Quantitative  Factors 

201.2.3  Field  Visits 

201 .2.4  Use  Study  Report  &  Updates 


202 

202.2.1 

202.2.2 

202.2.3 

202.2.4 


Mission  Hardware,  Software  and  Support  System 
Standardization 

Supportability  Constraints 
Supportability  Characteristics 
Recommended  Approaches 
Risks 


203 

203.2.1 

203.2.2 

203.2.3 

203.2.4 

203.2.5 

203.2.6 

203.2.7 

203.2.8 


Comparative  Analysis 
Identify  Comparative  Systems 
Baseline  Comparison  System 
Comparative  System  Characteristics 
Qualitative  Supportability  Problems 
Supportability,  Cost  and  Readiness  Drivers 
Unique  System  Drivers 
Updates 

Risks  and  Assumptions 
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Task/  Subtasks  Title 


204  Technological  Opportunities 

204.2.1  Recommended  Design  Objectives 

204.2.2  Updates 

204.2.3  Risks 


205  Supportability  and  Supportability  Related  Design  Factors 

205.2.1  Supportability  Characteristics 

205.2.2  Sensitivity  Analysis 

205.2.3  Identify  Proprietaty  Data 

205 .2 .4  Supportability  Obj  ectives  and  Associated  Risks 

205.2.5  Specialisation  Requirements 

205.2.6  Interoperability  (eg.  ABCA/NATO)  Constraints 

205.2.7  Supportability  Goals  and  Thresholds 


301 

301.2.1 

301.2.2 

301.2.3 

301.2.4 

301.2.5 

301.2.6 


Functional  Requirements 

Functional  Requirements 
Unique  Functional  Requirements 
Risks 

Operations  and  Maintenance  Tasks 

Design  Alternatives 

Updates 


302 

302.2.1 

302.2.2 

302.2.3 

302.2.4 

302.2.5 


Support  System  Alternatives 

Alternate  Support  Concepts 
Support  Concept  Updates 
Alternative  Support  Plans 
Support  Plan  Updates 
Risks 


303 

303.2.1 

303.2.2 

303.2.3 

303.2.4 

303.2.5 

303.2.6 

303.2.7 

303.2.8 

303.2.9 

303.2.10 

303.2.11 

303.2.12 

303.2.13 


Evaluation  of  Alternatives  and  Tradeoff  Analysis 
Tradeoff  Criteria 
Support  System  Tradeoffs 
System  Tradeoffs 
Readiness  Sensitivities 
Manpower  and  Personnel  Tradeoffs 
Training  Tradeoffs 
Level  of  Repair  Analysis 
Diagnostic  Tradeoffs 
Comparative  Evaluations 
Energy  Tradeoffs 
Survivability  Tradeoffs 
Transportability  Tradeoffs 
Support  Facility  Tradeoffs 
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Task/  Subtasks 
401 

401.2.1 

401.2.2 

401.2.3 

401.2.4 

401.2.5 

401.2.6 

401.2.7 

401.2.8 

401.2.9 

401.2.10 

401.2.11 

401.2.12 


Title 

Task  Analysis 
Task  Analysis 
Analysis  Documentation 
New/Critical  Support  Resources 
Training  Requirements  and  Recommendations 
Design  Improvements 
Management  Plans 
Transportability  Analysis 
Provisioning  Requirements 
Validation 
ILS  Output  Products 
LSAR  Updates 
Provisioning  Screening 


402  Early  Fielding  Analysis 

402.2.1  New  System  Impact 

402.2.2  Sources  of  Manpower  and  Personnel  Skills 

402.2.3  Impact  of  Resource  Shortfalls 

402.2.4  Combat  Resource  Requirements 

402.2.5  Plans  for  Problem  Resolution 


403  Post  Production  Support  Analysis 

403.2  Post  Production  Support  Plan 


501 

501.2.1 

501.2.2 

501.2.3 

501.2.4 

501.2.5 

501.2.6 


Supportability  Test,  Evaluation  and  Veriflcation 

Test  and  Evaluation  Strategy 

System  Support  Package  Component  List 

Objectives  and  Criteria 

Updates  and  Corrective  Actions 

Supportability  Assessment  Plan  (Post  Deployment) 

Supportability  Assessment  (Post  Deployment) 
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